Re: Random thoughts on sustained write performance

[David Wragg <dpw@doc.ic.ac.uk>]

Daniel Phillips <phillips@innominate.de> writes:
> > > Yes, correct.  Deferred allocation could let us run some filesystem
> > > transactions in parallel with the needed metadata reads.  Did you see
> > > my "[RFC] Generic deferred file writing" patch on lkml?  For each page
> > > in the generic_file_write we'd call the filesystem and it would
> > > initiate IO for the needed metadata.  The last of these reads could be
> > > asynchronous, and just prior to carrying out the deferred writes we'd
> > > wait for all the metadata reads to complete.  This hack would most
> > > likely be good for a few percent throughput improvement. It's a
> > > subtle point, isn't it? 
> > 
> > What's the reason for only making the last read asynchronous, rather
> > than all of them?
> 
> You don't know the block number of the bottom-level index block until
> you read its parents.

The index block reads need to be done in sequence before the write of
the block.  But I can't see why the process calling
generic_file_write needs to wait for any of the I/Os to complete.

I realize that this is a slight over-generalization, since ENOSPC
needs to be returned synchronously from write(2).


David
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/