From: Theodore Tso <tytso@mit.edu>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Problem with delayed allocation
Date: Mon, 4 Aug 2008 10:08:54 -0400 [thread overview]
Message-ID: <20080804140854.GE8592@mit.edu> (raw)
In-Reply-To: <20080804031652.GA11278@skywalker>
On Mon, Aug 04, 2008 at 08:46:52AM +0530, Aneesh Kumar K.V wrote:
> __fsync_super use filemap_fdatawait(mapping) for waiting on writeback
> pages. But all the dirty pages of the inode are not in writeback because
> we might have had block allocation failures.
Yes, but that should only happen if the filesystem is full or a user's
quota is overrun, correct?
> Also with the current code base I am seeing buffer_heads which are
> unmapped, non delay and dirty That means writepages won't allocate
> block for them and writepage cannot write them.
I thought all writes went through the page cache? Are you saying that
the *pages* are clean but the buffer_heads are marked dirty? In that
case, ext4_da_writepages, if wbc.sync_mode is not WB_SYNC_NONE, *must*
wait on them and not return until the buffers are safely on disk,
since filemap_fdatawait(mapping) won't in __sync_single_inode() won't
do the waiting for the writepages routine.
- Ted
next prev parent reply other threads:[~2008-08-04 14:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-02 20:07 Problem with delayed allocation Theodore Ts'o
2008-08-02 22:40 ` Theodore Tso
2008-08-04 3:16 ` Aneesh Kumar K.V
2008-08-04 14:08 ` Theodore Tso [this message]
2008-08-04 14:52 ` Aneesh Kumar K.V
2008-08-04 15:27 ` Aneesh Kumar K.V
2008-08-04 15:33 ` Aneesh Kumar K.V
2008-08-04 16:35 ` Aneesh Kumar K.V
2008-08-05 6:44 ` Theodore Tso
2008-08-05 6:52 ` Aneesh Kumar K.V
2008-08-05 13:21 ` Aneesh Kumar K.V
2008-08-05 13:47 ` Theodore Tso
2008-08-05 14:24 ` Aneesh Kumar K.V
2008-08-05 15:16 ` Theodore Tso
2008-08-06 10:05 ` Aneesh Kumar K.V
2008-08-06 10:11 ` Aneesh Kumar K.V
2008-08-07 0:49 ` Mingming Cao
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=20080804140854.GE8592@mit.edu \
--to=tytso@mit.edu \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=linux-ext4@vger.kernel.org \
/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