On Fri, 12 Jul 2013, Craig Sanders wrote:
e.g. once you've got a pool set up, get into the habit of creating subvolumes on the pool for different purposes rather than just sub-directories. You can enable different quotas (soft quota or hard-limit) on each volume, and have different attributes (e.g. compression makes sense for text documents, but not for already-compressed video files).
Note that `mv <tank/subvol1>/blbah <tank/subvol2>/foo` to different subvols on the same device still copies-then-deletes the data as if its a separate filesystem (it is - think of it just like lvms) despite the fact that it's all just shared storage in the one pool. Slightly inconvenient and surprising, but makes sense in a way (even if zfs could be convinced to mark a set of blocks from a file as changing its owner from subvol1 to subvol2, how do you teach `mv` that this inter-mount move is special?
1. if your disks are new and have 4K sectors OR if you're likely to add 4K-sector drives in future, then create your pool with 'ashift=12'
Do it anyway, out of habit. You will one day have 4k sectors, and migrating is a bitch (when you've maxed out the number of drives in your 4 bay NAS).
3. if you're intending to use some of that SSD for ZIL (write intent cache) then it's safer to have two ZIL partitions on two separate SSDs in a mirror configuration, so that if one SSD dies, you don't lose recent unflushed writes. this is one of those things that is low risk but high damage potential.
Terribly terribly low risk. It has to die, undetected, at the same time that the machine suffers from a power failure (ok, so these tend to be correlated failures). (I say undetected, because zpool status will warn you when any of its devices are unhealthy - set up a cron.hourly to monitor zpool status). And if it does die, then COW will mean you'll get a consistent 5 second old copy of your data. Which for non-database, non mailserver workloads (and database workloads for those of us who pay zillions of dollars for oracle, and then don't use it to its full potential), doesn't actually matter (5 seconds old data vs non-transactional data that would be 5 seconds old if the power failed 5 seconds ago? Who cares?) For me, SLOG just means that hardlinks over NFS don't take quite so long. Sometimes I even see SLOG usage grow up to 10MB(!) for a few seconds at a time! -- Tim Connors