From: Russell Cattelan <cattelan@thebarn.com>
To: Alexander Viro <viro@math.psu.edu>
Cc: Linus Torvalds <torvalds@transmeta.com>,
"Stephen C. Tweedie" <sct@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: Test12 ll_rw_block error.
Date: Sat, 16 Dec 2000 18:51:36 -0600 [thread overview]
Message-ID: <3A3C0E17.47E4F18B@thebarn.com> (raw)
In-Reply-To: <Pine.GSO.4.21.0012150150570.11106-100000@weyl.math.psu.edu>
Alexander Viro wrote:
> On Thu, 14 Dec 2000, Linus Torvalds wrote:
>
> > Good point.
> >
> > This actually looks fairly nasty to fix. The obvious fix would be to not
> > put such buffers on the dirty list at all, and instead rely on the VM
> > layer calling "writepage()" when it wants to push out the pages.
> > That would be the nice behaviour from a VM standpoint.
> >
> > However, that assumes that you don't have any "anonymous" buffers, which
> > is probably an unrealistic assumption.
> >
> > The problem is that we don't have any per-buffer "writebuffer()" function,
> > the way we have them per-page. It was never needed for any of the normal
> > filesystems, and XFS just happened to be able to take advantage of the
> > b_end_io behaviour.
> >
> > Suggestions welcome.
>
> Just one: any fs that really cares about completion callback is very likely
> to be picky about the requests ordering. So sync_buffers() is very unlikely
> to be useful anyway.
Actually no, that's not the issue.
The XFS log uses a LSN (Log Sequence Number) to keep track of log write ordering.
Sync IO on each log buffer isn't realistic; the performance hit would be to great.
I wasn't around when most of XFS was developed, but from I what I understand it
was discovered early on that firing off writes in a particular order doesn't
guarantee that
they will finish in that order. Thus the implantation of a sequence number for
each log write.
One of the obstacles we ran into early on in the linux port was the fact that
linux used fixed size IO requests to any given device.
But most of XFS's meta data structures vary in size in multiples of 512 bytes.
We were also implementing a page caching / clustering layer called
page_buf which understands primarily pages and not necessary
disk blocks. If your FS block size happens to match your page size then things
are good, but it doesn't....
So we added a bit map field to the pages structure.
Each bit then represents one BASIC BLOCK eg 512 for all practical purposes
The end_io functions XFS defines updates the correct bit or the whole bit array
if the whole page is valid, thus signaling the rest of the page_buf that the io
has
completed.
Ok there is a lot more to it than what I've just described but you probably get
the idea.
>
>
> In that sense we really don't have anonymous buffers here. I seriously
> suspect that "unrealistic" assumption is not unrealistic at all. I'm
> not sufficiently familiar with XFS code to say for sure, but...
>
> What we really need is a way for VFS/VM to pass the pressure on filesystem.
> That's it. If fs wants unusual completions for requests - let it have its
> own queueing mechanism and submit these requests when it finds that convenient.
>
> Stephen, you probably already thought about that area. Could you comment on
> that?
> Cheers,
> Al
--
Russell Cattelan
cattelan@thebarn.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-12-17 1:22 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3A398F84.2CD3039D@thebarn.com>
2000-12-15 6:20 ` Test12 ll_rw_block error Linus Torvalds
2000-12-15 7:00 ` Alexander Viro
2000-12-15 9:14 ` Chris Mason
2000-12-17 0:54 ` Russell Cattelan
2000-12-17 12:20 ` Chris Mason
2000-12-15 10:51 ` Stephen C. Tweedie
2000-12-15 19:04 ` Linus Torvalds
2000-12-17 1:08 ` Russell Cattelan
2000-12-18 11:44 ` Stephen C. Tweedie
2000-12-17 2:38 ` Marcelo Tosatti
2000-12-18 11:46 ` Stephen C. Tweedie
2000-12-19 14:05 ` Marcelo Tosatti
2000-12-19 16:43 ` Daniel Phillips
2000-12-19 17:18 ` Marcelo Tosatti
2000-12-19 17:40 ` Christoph Hellwig
2000-12-21 23:25 ` [RFC] changes to buffer.c (was Test12 ll_rw_block error) Chris Mason
2000-12-22 0:19 ` Marcelo Tosatti
2000-12-22 2:20 ` Andreas Dilger
2000-12-22 0:38 ` Marcelo Tosatti
2000-12-22 13:56 ` Chris Mason
2000-12-22 16:45 ` Daniel Phillips
2000-12-22 19:35 ` Chris Mason
2000-12-22 15:07 ` Chris Mason
2000-12-22 19:52 ` Marcelo Tosatti
2000-12-22 23:18 ` Chris Mason
2000-12-22 23:26 ` Marcelo Tosatti
2000-12-23 18:21 ` Chris Mason
2000-12-23 19:02 ` Linus Torvalds
2000-12-23 19:25 ` Chris Mason
2000-12-23 15:47 ` Daniel Phillips
2000-12-27 0:57 ` Chris Mason
2000-12-26 23:18 ` Marcelo Tosatti
2000-12-27 20:26 ` Daniel Phillips
2000-12-27 20:49 ` Chris Mason
2000-12-28 15:49 ` Daniel Phillips
2000-12-28 19:19 ` Chris Mason
2000-12-28 19:29 ` Linus Torvalds
2000-12-29 16:03 ` Chris Mason
2000-12-29 16:21 ` Marcelo Tosatti
2000-12-29 18:33 ` Alexander Viro
2001-01-05 15:54 ` Chris Mason
2001-01-05 15:43 ` Marcelo Tosatti
2001-01-05 17:49 ` Daniel Phillips
2001-01-05 17:52 ` Chris Mason
2001-01-05 19:51 ` Chris Mason
2001-01-05 18:32 ` Marcelo Tosatti
2001-01-05 20:29 ` Rik van Riel
2001-01-05 18:43 ` Marcelo Tosatti
2001-01-05 20:37 ` Rik van Riel
2001-01-05 21:08 ` Chris Mason
2001-01-05 18:09 ` Juergen Schneider
2000-12-29 17:58 ` Daniel Phillips
2001-01-02 15:49 ` Chris Mason
2000-12-22 1:54 ` Alexander Viro
2000-12-22 13:49 ` Chris Mason
2000-12-17 0:51 ` Russell Cattelan [this message]
2000-12-17 0:21 ` Test12 ll_rw_block error Russell Cattelan
2000-12-16 0:58 Jeff Chua
2000-12-16 1:12 ` Linus Torvalds
2000-12-16 17:13 ` Chris Mason
2000-12-16 19:07 ` Linus Torvalds
2000-12-16 19:35 ` Chris Mason
[not found] <3A398D58.92BBC9A4@thebarn.com>
2000-12-15 3:28 ` Linus Torvalds
-- strict thread matches above, loose matches on Subject: below --
2000-12-15 2:02 Russell Cattelan
2000-12-15 2:48 ` Linus Torvalds
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=3A3C0E17.47E4F18B@thebarn.com \
--to=cattelan@thebarn.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sct@redhat.com \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/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