All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Staubach <staubach@redhat.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
	Mark Fasheh <mark.fasheh@oracle.com>,
	Linux Memory Management <linux-mm@kvack.org>,
	linux-fsdevel@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>,
	OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
	Andrew Morton <akpm@google.com>
Subject: Re: Status of buffered write path (deadlock fixes)
Date: Wed, 13 Dec 2006 08:49:10 -0500	[thread overview]
Message-ID: <458004D6.7050406@redhat.com> (raw)
In-Reply-To: <1165977064.5695.38.camel@lade.trondhjem.org>

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?

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

    Thanx...

       ps

WARNING: multiple messages have this Message-ID (diff)
From: Peter Staubach <staubach@redhat.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
	Mark Fasheh <mark.fasheh@oracle.com>,
	Linux Memory Management <linux-mm@kvack.org>,
	linux-fsdevel@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>,
	OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
	Andrew Morton <akpm@google.com>
Subject: Re: Status of buffered write path (deadlock fixes)
Date: Wed, 13 Dec 2006 08:49:10 -0500	[thread overview]
Message-ID: <458004D6.7050406@redhat.com> (raw)
In-Reply-To: <1165977064.5695.38.camel@lade.trondhjem.org>

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?

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

    Thanx...

       ps

--
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-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2006-12-13 14:24 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-05  6:52 Status of buffered write path (deadlock fixes) Nick Piggin
2006-12-05  6:52 ` Nick Piggin
2006-12-07 19:55 ` Mark Fasheh
2006-12-07 19:55   ` Mark Fasheh
2006-12-08  3:28   ` Nick Piggin
2006-12-08  3:28     ` Nick Piggin
2006-12-08 23:48     ` Mark Fasheh
2006-12-08 23:48       ` Mark Fasheh
2006-12-11  9:11       ` Nick Piggin
2006-12-11  9:11         ` Nick Piggin
2006-12-11 14:20         ` Nick Piggin
2006-12-11 14:20           ` Nick Piggin
2006-12-11 15:52         ` Nick Piggin
2006-12-11 15:52           ` Nick Piggin
2006-12-11 16:12           ` Steven Whitehouse
2006-12-11 16:39             ` Nick Piggin
2006-12-11 16:39               ` Nick Piggin
2006-12-11 17:18               ` Steven Whitehouse
2006-12-11 17:18                 ` Steven Whitehouse
2006-12-12 22:31           ` Mark Fasheh
2006-12-12 22:31             ` Mark Fasheh
2006-12-13  0:53             ` Nick Piggin
2006-12-13  0:53               ` Nick Piggin
2006-12-13  1:47               ` Trond Myklebust
2006-12-13  1:47                 ` Trond Myklebust
2006-12-13  1:56                 ` Nick Piggin
2006-12-13  1:56                   ` Nick Piggin
2006-12-13  2:31                   ` Trond Myklebust
2006-12-13  2:31                     ` Trond Myklebust
2006-12-13  4:03                     ` Nick Piggin
2006-12-13  4:03                       ` Nick Piggin
2006-12-13 12:21                       ` Trond Myklebust
2006-12-13 12:21                         ` Trond Myklebust
2006-12-13 13:49                     ` Peter Staubach [this message]
2006-12-13 13:49                       ` Peter Staubach
2006-12-13 13:55                       ` Trond Myklebust
2006-12-13 13:55                         ` Trond Myklebust
2006-12-11 18:17 ` OGAWA Hirofumi
2006-12-11 18:17   ` OGAWA Hirofumi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=458004D6.7050406@redhat.com \
    --to=staubach@redhat.com \
    --cc=akpm@google.com \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.fasheh@oracle.com \
    --cc=nickpiggin@yahoo.com.au \
    --cc=trond.myklebust@fys.uio.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.