From: "Stephen C. Tweedie" <sct@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: "Stephen C. Tweedie" <sct@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: DVD blockdevice buffers
Date: Wed, 23 May 2001 20:57:48 +0100 [thread overview]
Message-ID: <20010523205748.L8080@redhat.com> (raw)
In-Reply-To: <20010523183419.I27177@redhat.com> <Pine.LNX.4.21.0105231104200.6320-100000@penguin.transmeta.com>
In-Reply-To: <Pine.LNX.4.21.0105231104200.6320-100000@penguin.transmeta.com>; from torvalds@transmeta.com on Wed, May 23, 2001 at 11:12:00AM -0700
Hi,
On Wed, May 23, 2001 at 11:12:00AM -0700, Linus Torvalds wrote:
>
> On Wed, 23 May 2001, Stephen C. Tweedie wrote:
> No, you can actually do all the "prepare_write()"/"commit_write()" stuff
> that the filesystems already do. And you can do it a lot _better_ than the
> current buffer-cache-based approach. Done right, you can actually do all
> IO in page-sized chunks, BUT fall down on sector-sized things for the
> cases where you want to.
Right, but you still lose the caching in that case. The write works,
but the "cache" becomes nothing more than a buffer.
This actually came up recently after the first posting of the
bdev-on-pagecache patches, when somebody was getting lousy
database performance for an application I think they had developed
from scratch --- it was using 512-byte blocks as the basic write
alignment and was relying on the kernel caching that. In fact, in
that case even our old buffer cache was failing due to the default
blocksize of 1024 bytes, and he had had to add an ioctl to force the
blocksize to 512 bytes before the application would perform at all
well on Linux.
So we do have at least one real-world example which will fail if we
increase the IO granularity. We may well decide that the pain is
worth it, but the page cache really cannot deal properly with this
right now without having an uptodate labeling at finer granularity
than the page (which would be unnecessary ugliness in most cases).
--Stephen
next prev parent reply other threads:[~2001-05-23 19:58 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-18 19:02 DVD blockdevice buffers Eduard Hasenleithner
2001-05-18 19:25 ` Jens Axboe
2001-05-18 19:59 ` Eduard Hasenleithner
2001-05-20 2:36 ` Linus Torvalds
2001-05-23 17:34 ` Stephen C. Tweedie
2001-05-23 18:12 ` Linus Torvalds
2001-05-23 19:57 ` Stephen C. Tweedie [this message]
2001-05-23 20:01 ` Linus Torvalds
2001-05-23 20:40 ` Jeff Garzik
2001-05-23 22:32 ` Andrea Arcangeli
2001-05-25 20:12 ` blkdev-pagecache-2 [was Re: DVD blockdevice buffers] Andrea Arcangeli
2001-05-25 20:15 ` Andrea Arcangeli
2001-05-23 22:09 ` DVD blockdevice buffers Andrea Arcangeli
2001-05-23 22:13 ` Alexander Viro
2001-05-23 22:24 ` Andrea Arcangeli
2001-05-24 11:36 ` Stephen C. Tweedie
2001-05-25 15:09 ` Eric W. Biederman
2001-05-25 15:45 ` Stephen C. Tweedie
2001-05-25 17:16 ` Linus Torvalds
2001-05-25 17:40 ` Alexander Viro
2001-05-25 18:05 ` Linus Torvalds
2001-05-25 18:24 ` Alexander Viro
2001-05-25 19:02 ` Stephen C. Tweedie
2001-05-27 6:38 ` Pavel Machek
2001-05-25 21:07 ` Eric W. Biederman
2001-05-25 21:18 ` Linus Torvalds
2001-05-25 22:31 ` Eric W. Biederman
-- strict thread matches above, loose matches on Subject: below --
2001-05-19 18:16 Adam Schrotenboer
2001-05-19 22:56 ` Jens Axboe
2001-05-20 1:55 ` Adam Schrotenboer
2001-05-21 15:44 ` Adam Schrotenboer
2001-05-21 15:47 ` Jens Axboe
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=20010523205748.L8080@redhat.com \
--to=sct@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox