On Sat, Jul 13, 2013 at 02:42:22PM +1000, Russell Coker wrote:
On Sat, 13 Jul 2013, Craig Sanders <cas@taz.net.au> wrote:
from the zfsonlinux faq:
http://zfsonlinux.org/faq.html#PerformanceConsideration
"Create your pool using whole disks: When running zpool create use whole disk names. This will allow ZFS to automatically partition the disk to ensure correct alignment. It will also improve interoperability with other ZFS implementations which honor the wholedisk property."
Who's going to transfer a zpool of disks from a Linux box to a *BSD or Solaris system? Almost no-one.
read the first reason again, automatic alignment of the partitions increases performance - and it's the sort of thing that it's a PITA to do manually, calculating the correct starting locations for all partitions. it'll be a lot more significant to most linux users than the second reason...as you say, that's irrelevant to most people.
But it does involve more data transfer. Modern SSDs shouldn't wear out, but I'm not so keen on testing that theory. For a system with a single SSD you will probably have something important on it. Using it for nothing but ZIL/L2ARC might be a good option, but also using it for boot probably wouldn't.
if you're that paranoid about SSDs wearing out then just don't use them for anything except a read-cache. or better yet, not at all. it really isn't worth worrying about, though. current generation SSDs are at least as reliable as hard disks, and with longevity to match. they're not going to wear out any faster than a hard disk.
On Fri, 12 Jul 2013, Craig Sanders <cas@taz.net.au> wrote:
0. zfsonlinux is pretty easy to work with, easy to learn and to use.
Actually it's a massive PITA compared to every filesystem that most Linux users have ever used.
yeah, well, it's a bit more complicated than mkfs. but a *lot* less complicated than mdadm and lvm.
I doubt that claim. It's very difficult to compare complexity, but the layered design of mdadm and lvm makes it easier to determine what's going on IMHO.
mdadm alone is simple enough and well documented, with great built-in help - about on a par with zfs. they're both very discoverable, which is particularly important for tools that you don't use daily, you typically only use them when adding or replacing hardware or when something has gone wrong. the btrfs tools are similarly easy to learn. lvm is the odd one out - it's reasonably well documented, but the built in help is crap, and it it is not easy to discover how to use the various lv tools or, indeed, which of the tools is the appropriate one to use - "is it lvresize or lvextend to resize a partition, or both but in what order"? and, unlike lvm, with both btrfs and zfs, once you've created the pool you don't need to remember or specify the device names of the disks in the pool unless you're replacing one of them - most operations (like creating, deleting, changing attributes of a volume or zvol) are done with just the name of the pool and volume. this leads to short, simple, easily understood command lines. btrfs and zfs are at a higher abstraction level, allowing you to work with the big picture of volumes and pools rather than get bogged down in little details of disks and partitions. the 'zpool history' command is also invaluable - you can easily see *exactly* which commands you used to make changes to the pool or a file system again - built in time-stamped cheat-notes of everything you've done to the pool. this makes it trivially easy to remember how you did something six months ago.
and gaining the benefits of sub-volumes or logical volumes of any kind is going to add some management complexity whether you use btrfs(8), zfs(8), or (worse) lvcreate/lvextend/lvresize/lvwhatever.
It's true that some degree of complexity is inherent in solving more complex problems. That doesn't change the fact that it's difficult to work with.
if you mean 'zfs is difficult to work with', then you must be using some definition of 'difficult' of which i was previously unaware. craig -- craig sanders <cas@taz.net.au> BOFH excuse #347: The rubber band broke