linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Neil Brown <neilb@suse.de>
To: Nick Piggin <npiggin@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linux Filesystems <linux-fsdevel@vger.kernel.org>,
	Mark Fasheh <mark.fasheh@oracle.com>,
	Linux Memory Management <linux-mm@kvack.org>
Subject: Re: [patch 12/44] fs: introduce write_begin, write_end, and perform_write aops
Date: Tue, 24 Apr 2007 16:59:47 +1000	[thread overview]
Message-ID: <17965.43747.979798.715583@notabene.brown> (raw)
In-Reply-To: message from Nick Piggin on Tuesday April 24

On Tuesday April 24, npiggin@suse.de wrote:
> +  write_begin: This is intended as a replacement for prepare_write. Called
> +        by the generic buffered write code to ask the filesystem to prepare
> +        to write len bytes at the given offset in the file. flags is a field
> +        for AOP_FLAG_xxx flags, described in include/linux/mm.h.

Putting "This is intended as a replacement.." there sees a bit
dangerous.  It could well accidentally remain when the documentation
for prepare_write gets removed.  I would make it a separate paragraph
and flesh it out.  And include text from prepare_write before that
gets removed.

   write_begin:
         This is intended as a replacement for prepare_write.  The key 
         differences being that:
		- it returns a locked page (in *pagep) rather than
                  being given a pre-locked page:
		- it can pass arbitrary state to write_end rather than
		  having to hide stuff in some filesystem-internal
	          data structure 
		- The (largely undocumented) flags option.

         Called by  the generic bufferred write code to ask an
         address_space to prepare to write len bytes at the given
         offset in the file.

	 The address_space should check that the write will be able to
  	 complete, by allocating space if necessary and doing any other
  	 internal housekeeping.  If the write will update parts of any
  	 basic-blocks on storage, then those blocks should be pre-read
  	 (if they haven't been read already) so that the updated blocks
  	 can be written out properly.
	 The possible flags are listed in include/linux/fs.h (not
  	 mm.h) and include
		AOP_FLAG_UNINTERRUPTIBLE:
			It is unclear how this should be used.  No
		  	current code handles it.

(together with the rest...)
> +
> +        The filesystem must return the locked pagecache page for the caller
> +        to write into.
> +
> +        A void * may be returned in fsdata, which then gets passed into
> +        write_end.
> +
> +        Returns < 0 on failure, in which case all cleanup must be done and
> +        write_end not called. 0 on success, in which case write_end must
> +        be called.


As you are not including perform_write in the current patchset, maybe
it is best not to include the documentation yet either?

> +  perform_write: This is a single-call, bulk version of write_begin/write_end
> +        operations. It is only used in the buffered write path (write_begin
> +        must still be implemented), and not for in-kernel writes to pagecache.
> +        It takes an iov_iter structure, which provides a descriptor for the
> +        source data (and has associated iov_iter_xxx helpers to operate on
> +        that data). There are also file, mapping, and pos arguments, which
> +        specify the destination of the data.
> +
> +        Returns < 0 on failure if nothing was written out, otherwise returns
> +        the number of bytes copied into pagecache.
> +
> +        fs/libfs.c provides a reasonable template to start with, demonstrating
> +        iov_iter routines, and iteration over the destination pagecache.
> +

NeilBrown

--
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>

  reply	other threads:[~2007-04-24  6:59 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070424012346.696840000@suse.de>
2007-04-24  1:23 ` [patch 01/44] mm: revert KERNEL_DS buffered write optimisation Nick Piggin
2007-04-24  1:23 ` [patch 02/44] Revert 81b0c8713385ce1b1b9058e916edcf9561ad76d6 Nick Piggin, Andrew Morton
2007-04-24  1:23 ` [patch 03/44] Revert 6527c2bdf1f833cc18e8f42bd97973d583e4aa83 Nick Piggin, Andrew Morton
2007-04-24  1:23 ` [patch 04/44] mm: clean up buffered write code Nick Piggin, Andrew Morton
2007-04-24  1:23 ` [patch 05/44] mm: debug write deadlocks Nick Piggin
2007-04-24  1:23 ` [patch 06/44] mm: trim more holes Nick Piggin
2007-04-24  6:07   ` Neil Brown
2007-04-24  6:17     ` Nick Piggin
2007-04-24  1:23 ` [patch 07/44] mm: buffered write cleanup Nick Piggin
2007-04-24  1:23 ` [patch 08/44] mm: write iovec cleanup Nick Piggin
2007-04-24  1:23 ` [patch 09/44] mm: fix pagecache write deadlocks Nick Piggin
2007-04-24  1:23 ` [patch 10/44] mm: buffered write iterator Nick Piggin
2007-04-24  1:23 ` [patch 11/44] fs: fix data-loss on error Nick Piggin
2007-04-24  1:23 ` [patch 12/44] fs: introduce write_begin, write_end, and perform_write aops Nick Piggin
2007-04-24  6:59   ` Neil Brown [this message]
2007-04-24  7:23     ` Nick Piggin
2007-04-24  7:49       ` Neil Brown
2007-04-24 10:37         ` Nick Piggin
2007-04-24  1:23 ` [patch 13/44] mm: restore KERNEL_DS optimisations Nick Piggin
2007-04-24 10:43   ` Christoph Hellwig
2007-04-24 11:03     ` Nick Piggin

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=17965.43747.979798.715583@notabene.brown \
    --to=neilb@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.fasheh@oracle.com \
    --cc=npiggin@suse.de \
    /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