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..