On Mon, 15 Jul 2013 14:30:43 +1000 Craig Sanders <cas@taz.net.au> wrote:
oh well, consider that an example of lvm's difficulty to learn and remember. I've been using LVM for a lot longer than ZFS but I still find it difficult and complicated to work with, and the tools are clumsy and awkward.
They are designed for first-generation filesystems where fsck is a standard utility that's regularly used as opposed to more modern filesystems where there is no regularly used fsck because they are just expected to work all the time. The ratio of block device size to RAM for affordable desktop systems is now around 500:1 (4T:8G) where it was about 35:1 in the mid 90's (I'm thinking 70M disk and 2M of RAM). The time taken to linearly read an entire block device is now around 10 hours when it used to be about 2 minutes in 1990 (I'm thinking of a 1:1 interleave 70MB MFM disk doing 500KB/s). Those sort of numbers change everything about filesystems, and they aren't big filesystems. The people who designed ZFS were thinking of arrays of dozens of disks as a small filesystem. Ext4 and LVM still have their place. I'm a little nervous about the extra complexity of ZFS and BTRFS when combined with a system that lacks ECC RAM. I've already had two BTRFS problems that required backup/format/restore due to memory errors.
nowadays, i see them as first generation pool & volume management tools, functional but inelegant. later generation tools like btrfs and ZFS not only add more features (like compression, de-duping, etc etc) by blurring the boundaries between block devices and file systems but more importantly they add simplicity and elegance that is missing from the first generation.
True, but they also add complexity. Did you ever run debugfs on an ext* filesystem? It's not that hard to do. I really don't want to imagine running something similar on BTRFS or ZFS.
and as for lvextend, lvreduce, and lvresize - it's completely insane for there to be three tools that do basically the same job.
It's pretty much standard in Unix to have multiple ways of doing it. gzip -d / zcat cp / tar / cat / mv all have overlapping functionality tar / cpio
sure, i get that there are historical and compatibility reasons to keep lvextend and lvreduce around, but they should clearly be marked in the man page as "deprecated, use lvresize instead" (or even just "same as lvresize") because for a newcomer to LVM or even a long term
So it's a man page issue. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/