Actually RAID/volume management is superlimited when not in filesystem...
Posted Jan 17, 2009 21:34 UTC (Sat) by speedster1
In reply to: Actually RAID/volume management is superlimited when not in filesystem...
Parent article: Btrfs aims for the mainline
What you're asking for in a couple of your other posts, however, is not a simple thing. It doesn't fit well with how computers work in general. You seem to be saying you want to just save something and have the computer magically understand that it's "important" or "not important" or "kind of important" and know what that means. But computers don't do that. Someone has to tell them what each of those categories means, and how they're defined. And since it's your data, it's going to be hard for someone else to do that.
I don't think this automatic classification of "importance" is really the killer feature khim is pining for! There are a couple of key things that are painful or impossible with current LVM+RAID (which khim does know about and is currently using, for lack of a better alternative):
- allocation of space among the areas of differing redundancy
- ability to store metadata in a higher-redundancy area than the corresponding normal data
If the normal filesystem in your example 10GB partition of high-redundancy storage fills up, your app will get an out-of-space error and you will have to hack around with LVM tools to try to reclaim some space from that big RAID 5 partition. Are you at all confident that a typical user could shrink it safely? I think a typical user would end up having to buy more disks, even though there was lots of unused space in the existing disks!
In a smart filesystem that handled levels of redundancy internally, you would not have this problem at all. The filesystem would have one big pool of storage, and would create additional regions of high redundancy as needed.
I know it is possible to put filesystem journals on separate partitions, but I don't think point #2 is even possible with current filesystems.
to post comments)