lkml.org 
[lkml]   [1998]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Ordered block writes
Date
> 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
>


\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.036 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site