Messages in this thread | | | From | "Stephen D. Williams" <> | Subject | Re: Ordered block writes | Date | Sun, 1 Feb 1998 18:33:09 -0500 (EST) |
| |
> Stephen D. Williams wrote: > > I like versioning systems (such as database versioning of tuples) and > > I think of these ID's as 'generations'. Each commit/'sync' (at the > > file system level) generates a new generation ID, after finishing off > > the old one. > > Yes, that would be suitable for my purposes. > > There was one other thing I forgot to mention though: if a block has a > change which is *not* being committed in the current transaction, it > shouldn't be written. In other words, there needs to be a "dirty but > unwritable" state.
I think that you have to allow the write, just not require it and possibly only put it in the queue after the normal 'dirty' blocks are written. In other words, you can't say that blocks aren't Ever written until they are committed because you either have to place arbitrary constraints on usage or have problems like writing a file the size of the whole filesystem before committing.
Placing inheritable priority on blocks with or in addition to the generational ID could accomplish this. Lower priority pools would only be processed after higher priority blocks/pools were completed and empty.
sdw
... > J >
| |