A most enlightening thread so far. I've begun playing with ZFS within a VM to get used to the various commands and their outcomes etc.
From what I've been reading elsewhere what I like about ZFS is the reduction (or is simplification more appropriate) of something like this (hoping my ASCII art holds up):
[/] [/usr] [/var] [/home] | | | | +---------------------------+ | volume group "vg" | +---------------------------+ | | +-----------+ +-----------+ |PV /dev/foo| |PV /dev/bar| +-----------+ +-----------+ | | | | sda sdb sdc sdd ....to something like this: [zfs "tank/"] [zfs "tank/usr"] [zfs "tank/home"] | | | +-------------------------------------------------+ | stroage pool "tank" | +-------------------------------------------------+ | | | | sda sdb sdc sdd I also like how block-device management knows about the file system or vice-versa and can therefore cope with errors. I've experienced the disconnection between fs, mdadm and the disk not long ago when a corruption occurred in an episode of the West Wing that we didn't discover until we re-watched it. The corruption was even passed onto the back-up copies. Recovery was as simple as re-capturing from source but a pain none the less. One thing I read yesterday was that zfs can be prone to issues from fragmentation - is there a preventive strategy or remedial measure to take into account? On 15 July 2013 14:30, Craig Sanders <cas@taz.net.au> wrote:
On Sun, Jul 14, 2013 at 05:25:29PM +1000, Brett Pemberton wrote:
to extend or resize the volume, you've got to tell it which disk(s) to allocate the free space from.
Nope. You can, but you don't have to.
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.
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.
and as for lvextend, lvreduce, and lvresize - it's completely insane for there to be three tools that do basically the same job. 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 but infrequent user (as is normal, lvm isn't exactly daily-usage) they just add confusion - i have to remind myself every time I use them that extend doesn't mean anything special in LVM, it's not something extra i have to do before or after a resize, it's just a resize.
craig
-- craig sanders <cas@taz.net.au>
BOFH excuse #144:
Too few computrons available. _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
-- Colin Fee tfeccles@gmail.com