Aggelos Economopoulos wrote:
>> do we even *need* volume managment?
>
> No, we can just duplicate a shitload of work inside hammer.
I think I was misunderstood here ..
Personally - I am a big fan of volume management, data separation, etc -
My setup at the moment uses like 3m VN disks, I leave freespace so I can
shuffle the disklabels around, etc.
my point was simply - with a filesystem that supports size-bounded
'native' pseudo-filesystems, having volume managment as a separate layer
might be an unecessary complication.. with lots of unneeded extra
complicated bits to code and test..
For example: When's the last time you moved an LV from one disk area to
another on an lvm system that had growable/shrinkable filesystems?
If you had to do it (god knows why), would you be really mad if it broke
because no one had tested it in the last release?
Likewise, would you be really mad if when rebuilding a critical RAID
dataset with a flaky drive, your machine crashed because it hit some
kernel bug inside multipathing code you weren't even using..?
Personally, all I need a volume manager to do is to size-bound datasets,
with the ability to dynamically change those size-bounds while the
system is online, and if hammer had built in min/max prune/block/free
pfs size limits all of these things would be done, without the need for
a new volume manager. Yes, crypt and raid and multipath are nice - but
as I see it, these are all different problems..
