From: Andrew Morton <akpm@linux-foundation.org>
To: Alex Tomas <alex@clusterfs.com>
Cc: Eric Sandeen <sandeen@redhat.com>,
"Theodore Ts'o" <tytso@mit.edu>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: booked-page-flag.patch
Date: Thu, 15 Feb 2007 23:46:40 -0800 [thread overview]
Message-ID: <20070215234640.d52e5908.akpm@linux-foundation.org> (raw)
In-Reply-To: <m3sld636g0.fsf@bzzz.home.net>
On Fri, 16 Feb 2007 10:30:39 +0300 Alex Tomas <alex@clusterfs.com> wrote:
> >>>>> Andrew Morton (AM) writes:
>
> -> get_block(with BH_Delay) can be used to signal
> >> filesystem that no actual allocation is required.
> >> so, aware filesystem can just reserve space. then
> -> writepages() should walk through the pages like
> >> it does currently, collect contiugous sequences
> >> and again call ->get_block(w/o BH_Delay) with b_size
> >> covering all contiguous pages ...
> >>
>
> AM> That sounds like it'd work, yes.
>
> AM> Except for an address_space which is using delayed allocation, its
> -> prepare_write wouldn't call get_block at all, so perhaps that isn't
> AM> needed.
>
> hmm. I thought it has to call get_block() at least to know whether
> the block is already allocated. and I was going to reserve space
> in prepare_write for which some fs-specific method is needed becase
> only fs knows how much metadata it'd need.
Well, one could just assume that the page has no disk mapping and go and
make the space reservation. Things will work out OK when we come to do
writepage().
Or one could do both: call get_block() only if the page was inside i_size.
next prev parent reply other threads:[~2007-02-16 7:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-15 8:45 booked-page-flag.patch Andrew Morton
2007-02-15 14:03 ` booked-page-flag.patch Alex Tomas
2007-02-15 17:18 ` booked-page-flag.patch Eric Sandeen
2007-02-15 17:30 ` booked-page-flag.patch Alex Tomas
2007-02-15 20:56 ` booked-page-flag.patch Andrew Morton
2007-02-15 21:07 ` booked-page-flag.patch Alex Tomas
2007-02-15 23:23 ` booked-page-flag.patch Andrew Morton
2007-02-16 7:30 ` booked-page-flag.patch Alex Tomas
2007-02-16 7:46 ` Andrew Morton [this message]
2007-02-16 7:56 ` booked-page-flag.patch Alex Tomas
2007-02-16 8:06 ` booked-page-flag.patch Andrew Morton
2007-02-16 12:14 ` booked-page-flag.patch Andreas Dilger
2007-02-16 16:02 ` booked-page-flag.patch Dave Kleikamp
2007-02-16 15:03 ` booked-page-flag.patch Theodore Tso
2007-02-15 20:21 ` booked-page-flag.patch Andrew Morton
2007-02-16 12:17 ` booked-page-flag.patch Andreas Dilger
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=20070215234640.d52e5908.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=alex@clusterfs.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=tytso@mit.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.