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 <[email protected]> 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 <[email protected]>
>
> BOFH excuse #144:
>
> Too few computrons available.
> _______________________________________________
> luv-main mailing list
> [email protected]
> http://lists.luv.asn.au/listinfo/luv-main
>
--
Colin Fee
[email protected]
_______________________________________________
luv-main mailing list
[email protected]
http://lists.luv.asn.au/listinfo/luv-main
