lkml.org 
[lkml]   [1998]   [Jun]   [28]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSun, 28 Jun 1998 18:26:07 -0700
FromHans Reiser <>
SubjectRe: (reiserfs) Some newbie questions about the interface between FS's and LVM's
I'm sorry, I just got out of a cool shower and decided I shouldn't call block groups strange and bizaare.  I just prefer tree
ordering is all.

Hans

Hans Reiser wrote:
> 
> Reiserfs is getting close to the point where I should worry about its interaction with disk management software.
> 
> 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

\
 
 \ /
  Last update: 2005-03-22 12:43    [from the cache]
©2003-2008