All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Anton Altaparmakov <aia21@cus.cam.ac.uk>
Cc: Alexander Viro <viro@math.psu.edu>,
	Linus Torvalds <torvalds@transmeta.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [prepatch] address_space-based writeback
Date: Thu, 11 Apr 2002 16:03:23 -0700	[thread overview]
Message-ID: <3CB6163B.EAC8F633@zip.com.au> (raw)
In-Reply-To: <3CB5FFB5.693E7755@zip.com.au> <Pine.SOL.3.96.1020411235415.24708A-100000@virgo.cus.cam.ac.uk>

Anton Altaparmakov wrote:
> 
> ...
> It would be great to be able to submit variable size "io entities" even
> greater than PAGE_CACHE_SIZE (by giving a list of pages, starting offset
> in first page and total request size for example) and saying write that to
> the device starting at offset xyz. That would suit ntfs perfectly. (-:
> 

Yes, I'll be implementing that.  Writeback will hit the filesystem
via a_ops->writeback_mapping(mapping, nr_pages).  The filesytem
will then call in to generic_writeback_mapping(), which will walk
the pages, assemble BIOs and send them off.

The filesystem needs to pass a little state structure into the
generic writeback function.  An important part of that is a
semaphore which is held while writeback is locking multiple
pages.  To avoid ab/ba deadlocks.

The current implementation of this bio-assembler is for no-buffer
(delalloc) fileystems only.  It need to be enhanced (or forked)
to also cope with buffer-backed pages. It will need to peek
inside the buffer-heads to detect clean buffers (maybe.  It
definitely needs to skip unmapped ones).  When such a buffer
is encountered the BIO will be sent off and a new one will be started.
The code for this is going to be quite horrendous.  I suspect
the comment/code ratio will exceed 1.0, which is a bad sign :)

One thing upon which I am undecided:  for syncalloc filesystems
like ext2, do we attach buffers at ->readpages() time, or do
we just leave the page bufferless?

That's a hard call.  It helps the common case, but in the uncommon
case (we overwrite the file after reading it), we need to run
get_block again.

-

  reply	other threads:[~2002-04-12  0:05 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-10 11:21 [prepatch] address_space-based writeback Andrew Morton
2002-04-10 11:34 ` Alexander Viro
2002-04-10 19:16   ` Andrew Morton
2002-04-10 20:53     ` Alexander Viro
2002-04-10 22:12     ` Jan Harkes
2002-04-10 21:44       ` Andrew Morton
2002-04-10 22:56         ` Anton Altaparmakov
2002-04-10 22:31           ` Andrew Morton
2002-04-11 20:20           ` Linus Torvalds
2002-04-11 20:41             ` Alexander Viro
2002-04-11 21:27               ` Andrew Morton
2002-04-11 22:55                 ` Andreas Dilger
2002-04-11 22:49                   ` Andrew Morton
2002-04-12  0:12                     ` Linus Torvalds
2002-04-11 23:10                   ` Christoph Hellwig
2002-04-11 23:22                 ` Anton Altaparmakov
2002-04-11 23:03                   ` Andrew Morton [this message]
2002-04-12  4:19                   ` Bill Davidsen
2002-04-12  1:15             ` Anton Altaparmakov
2002-04-12  1:37               ` Linus Torvalds
2002-04-12  7:57                 ` Anton Altaparmakov
2002-04-27 15:53                   ` Jan Harkes
2002-04-28  3:03                     ` Anton Altaparmakov
2002-04-29  9:03                       ` Nikita Danilov
2002-04-29 11:11                         ` Anton Altaparmakov
2002-04-29 11:59                           ` Nikita Danilov
2002-04-29 12:34                             ` Anton Altaparmakov
2002-04-29 13:01                               ` Christoph Hellwig
2002-04-30 17:19                             ` Denis Vlasenko
2002-04-30 13:15                               ` john slee
2002-04-30 13:24                                 ` Billy O'Connor
2002-04-30 13:36                                   ` jlnance
2002-04-30 13:40                                 ` Keith Owens
2002-05-01 19:18                                   ` Denis Vlasenko
2002-05-02  8:49                                     ` Anton Altaparmakov
2002-05-03 15:35                                       ` Denis Vlasenko
2002-05-03 12:49                                         ` Helge Hafting
2002-05-03 22:47                                           ` Denis Vlasenko
2002-05-03 21:50                                             ` Anton Altaparmakov
2002-05-05  0:46                                               ` Denis Vlasenko
2002-05-03  7:56                                     ` Pavel Machek
2002-05-03 14:48                                     ` Rob Landley
2002-05-05  0:42                                       ` Denis Vlasenko
2002-04-30 16:12                                 ` Peter Wächtler
2002-04-10 23:02         ` Jan Harkes
2002-04-10 19:29 ` Jeremy Jackson
2002-04-10 19:41   ` Andrew Morton
2002-04-15  8:47 ` Andrew Morton

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=3CB6163B.EAC8F633@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=aia21@cus.cam.ac.uk \
    --cc=linux-kernel@vger.kernel.org \
    --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 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.