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