Once upon a time, Theodore Tso <[email protected]> said:
>The people who want ZFS have in mind certain features, such as the
>ability to scale to very large sizes, and ease of use when
>administering filesystems that span multiple disks (ZFS subsumes the
>device-mapper/RAID layer in Solaris, so they get certain performance
>benefits and they are able to make it simpler to set up a filesystem
>that spans multiple disks with a single command --- the flip side is
>that they are violating an relatively well understood abstraction
>boundary, for better or for worse).
I haven't used ZFS, but I do manage servers with Tru64 Unix AdvFS
filesystems. Having some of the logical volume functionality merged in
the filesystem layer does seem to be a good thing. For example,
snapshotting a filesystem can use free space in the filesystem (without
having to set aside unused logical volume space for snapshotting).
Expanding the filesystem is simple: "addvol <device> <AdvFS domain>" and
go (no adding to the volume group, extending the logical volume, and
resizing the filesystem). Shrinking the filesystem is just as easy
(currently you can't even do that live with ext3).
I know this violates the Linux layering. However, AdvFS has done this
for years (in a single-system-image cluster environment even), and now I
guess ZFS does it as well. Maybe the Linux layering needs a revision to
handle something like this?
I'm just speaking as a system admin that prefers Linux everywhere, but
does like (and will miss) a few things about Tru64/TruCluster.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
