DragonFly BSD
DragonFly kernel List (threaded) for 2010-04
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Google Summer of Code idea


From: Chris Turner <c.turner@xxxxxxxxxxxxxxxxxxx>
Date: Thu, 01 Apr 2010 02:00:50 +0000

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









[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]