On Tue, 2005-04-19 at 13:41, Martin Jambor wrote: > > > > 1) Currently none of the generic helper routines can handle this. > > We need to add support to do these, but still somehow make the > > routines generic enough for every ones use. > > I'm quite happy about most of them. I can't see how we could use any > generic form of writepage(s) as we write stuff in a quite different > way from almost anybody else but all the others except > block_prepare_write do pretty much exactly what we need (if I have > not missed something).
Yep. You need to have your own block_prepare_write() which doesn't allocate a block - instead it "reserves" a block. > > > 2) There is no easy way to find out if we "reserved" a block or > > not in writepage() correctly. There are 2 paths to writepage(). > > > > sys_write() -> prepare/commit() > > and later sync() ----> writepage() > > > > mmap() -> touch a page() > > and later --> writepage() > > > > In order to do the correct accounting, we need to mark a page > > to indicate if we reserved a block or not. One way to do this, > > to use page->private to indicate this. But then, all the generic > > routines will fail - since they assume that page->private represents > > bufferheads. So we need a better way to do this. > > I didn't hope for a special bit in struct page so I wanted to simply > fake the page/buffer mapping somehow. Since we don't really care > whether a page is mapped or reserved as long as it is at least one of > these when actually writing it (we write stuff to different places > from where we have read it from), the PG_mappedtodisk is fine for us > as long as no other kernel code thinks that having it set means we > also have buffers which point to meaningful positions on the device > because we don't. Is that the case? > > Of course, having a PG_RESERVED flag would be a nice and clean thing > to use and we would be more than happy to do so. > > > 3) We need add hooks into filesystem specific calls from these > > generic routines to handle "journaling mode" requirements > > Our fs is basically one big journal so we don't need any of these. Or > at least I don't see any need for it at the moment. > > > So, what are your requirements ? I am looking for a common > > way to combine all the requirements and come out with a > > saner "generic" routines to handle these. > > I'm happy with most generic functions. we need to implement > writepage(s) ourselves no matter what, the only problem is > block_prepare_write and I can currently only see two options for us: > > 1) Implement it ourselves and use a flag in the struct page to mark it > reserved. > > 2) Use block_prepare_write but enable the get_block function to mark > an individual buffer as reserved so that it is trated as mapped (can > be dirty and stuff) but no code assumes it is located somewhere on the > disk (for example block_prepare_write would not call > unmap_underlying_metadata). > > I think we'll go for the first method, but the second would make life > easier for filesystems which can have pages consisting of both mapped > and reserved blocks. I guess for now, you can do all this in your filesystem specific code. Too bad, every one has to write their own. Hopefully, we cleanup all these interfaces and provide a generic *enough* interfaces to do this - so everyone can use it. As you can see, lots of issues need to be worked out + I don't have bandwidth to undertake such an effort, unless Nikita and Bryan are willing to signup for this :) Thanks, Badari - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
