[Tux3] Block handle demo code

[Daniel Phillips]

On Saturday 22 November 2008 06:56, OGAWA Hirofumi wrote:
> Daniel Phillips <phillips at phunq.net> writes:
> 
> > I'm just going to post this block handles demo code now and save my 
> > traditional long winded explanation for later.  In brief: we think we 
> > might make a clean break from buffer_head in Tux3.  If so, we still 
> > need locking and IO handles for blocks when block size is smaller than 
> > a memory page.  That is what this code is for: in a page cache, each 
> > page->private will point at a struct handles, holding the state of up 
> > to eight buffers in a single 16 byte struct (32 bytes on 64 bit arch).
> 
> For the record: it may have to handle HIGHMEM issue, e.g. kmap_atomic()
> or something? Or we use GFP_USERS or something (at least wouldn't use
> for file data)? At least I was not thinking about it.

Yes it does have to handle highmen unless we want to abandon support
for highmem on 32 bit systems, which is tempting.  But supporting
highmem is not hard.  Our bread equivalent only has to handle zeroing
unmapped pages.  There is even a zero_user library call now.

If we want, we can handle directory blocks strictly in kernel memory
like Ext3 does.  Otherwise, we would need a map/unmap api to access
handle data after a bread, with a maximum of two blocks mapped at the
same time (KM_USER0, KM_USER1).  Our blockget() can take a GFP
parameter to specify whether to map exclusively into kernel memory or
not, and for now we can handle all metadata in kernel memory, even
when the metadata is mapped into file page cache, like directories,
bitmaps, atom table etc.  For regular files, I don't think we ever
need to blockread(), and no need to map highmem.

Daniel

_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://tux3.org/cgi-bin/mailman/listinfo/tux3