Re: Design problems caused by bdflush

[Daniel Phillips]

Jamie Lokier wrote:
> Daniel Phillips wrote:
> > In the end I think that the buffer system ought to be virtualized in
> > the same way as the rest of vfs, with some as-yet unidentified set of
> > operations that can be taken as defaults or overridden as required.
> > This would allow the buffer behaviour to be tuned on a
> > per-filesystem/partition basis, which would be right and proper.
> 
> A possibly simple change would be another buffer state: "dependent
> dirty".  Unlike dirty buffers they are not flushed and they're not on
> the dirty list; instead, they are linked to from an ordinary dirty
> buffer.
> 
> After an ordinary dirty buffer is written or flushed, its "dependent
> dirty" buffers are changed to "dirty" and they will eventually be
> written too.  Thus you get a partial write ordering.
> 
> The API is mark_buffer_dependent_dirty(buffer, parent), nothing more.

Priority sorting of disk writes is an interesting idea that I haven't explored
and probably should, but my immediate application doesn't fit that model. 
My dirty buffers fall into two categories: those that can't be written yet and
those that can.  When all the writeable blocks have been written, all the
unwriteable blocks become writeable.  So priority sorting doesn't capture this
very well - priority sorting would be suitable if the relationships were more
complex.

all my unwriteable dirty blocks on the locked list and that would probably work
although that certainly isn't what the locked list was intended for.  I'd
appreciate opinions about this.

I'd still be faced with the problem of what to do about sync_buffers - I really
need the sync function to be virtualized (a la file_operations) so I can just
sync the blocks that need to be synced, and not sync the blocks that would
overwrite part of an existing, consistent filesystem image.

-- 
Daniel