I don't know much about disk management software, except as a former sysadmin for most of the major Unixes.
I am only familiar with disk management software as a former sysadmin, so I have some newbie thoughts that I'd like to explore.
Let's consider the question, what would be the minimal complexity yet still optimal interface between a multi-device abstraction
layer, and an FS. I say minimal, because I want to implement the bare minimum first.
I think I would like to see:
* a bitmap,
* a driver that converts the I/O, that I (ReiserFS) send using device and logical block numbers for that abstract device, into
requests that go to disk drivers for the non-abstracted devices below its abstraction layer,
* a call for asking me to shift everything in the FS to the right or left and tree-order it as I do it (for a tree fs making the
logical block numbers correspond to the tree ordering is like defragging but a little better),
* a call for asking me to shift everything out of some range of blocks and mark them all used even though they are free with a
return result of insufficient space and everything being freed again for the FS to use being possible for me to return if I fail,
* a bitmap lock,
* and a call to ask me to switch from an old bitmap to a new bitmap.
That is what I think I would like to see, what should I want to see, and what do I actually get?
Note that I can easily come up with a great many things that I should want sometime in the future that will let me choose to
understand the structure of the underlying disks, and how to optimize for that. I think I should only ask you for them when I am
ready to implement code for employing them, which I don't think is this year.
Do these 4mb partition thingies have their roots in the implementation of other file systems (perhaps being related to these
strange and bizarre block group thingies), and do we really need to and want to employ abstractions other than block ranges and
bitmaps as our base abstractions?
Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu