lkml.org 
[lkml]   [2006]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Status of buffered write path (deadlock fixes)
From
Date
On Wed, 2006-12-13 at 08:49 -0500, Peter Staubach wrote:
> Trond Myklebust wrote:
> > On Wed, 2006-12-13 at 12:56 +1100, Nick Piggin wrote:
> >
> >> Note that these pages should be *really* rare. Definitely even for normal
> >> filesystems I think RMW would use too much bandwidth if it were required
> >> for any significant number of writes.
> >>
> >
> > If file "foo" exists on the server, and contains data, then something
> > like
> >
> > fd = open("foo", O_WRONLY);
> > write(fd, "1", 1);
> >
> > should never need to trigger a read. That's a fairly common workload
> > when you think about it (happens all the time in apps that do random
> > write).
>
> I have to admit that I've only been paying attention with one eye, but
> why doesn't this require a read? If "foo" is non-zero in size, then
> how does the client determine how much data in the buffer to write to
> the server?

That is what the 'struct nfs_page' does. Whenever possible (i.e.
whenever the VM uses prepare_write()/commit_write()), we use that to
track the exact area of the page that was dirtied. That means that we
don't need to care what is on the rest of the page, or whether or not
the page was originally uptodate since we will only flush out the area
of the page that contains data.

> Isn't RMW required for any i/o which is either not buffer aligned or
> a multiple of the buffer size?

Nope.

Cheers,
Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-12-13 14:59    [W:0.290 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site