From: Zach Brown <zach.brown@oracle.com>
To: David Chinner <dgc@sgi.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: correct use of vmtruncate()?
Date: Tue, 29 Apr 2008 10:10:59 -0700 [thread overview]
Message-ID: <481756A3.20601@oracle.com> (raw)
In-Reply-To: <20080429100601.GO108924158@sgi.com>
> The obvious fix for this is that block_write_begin() and
> friends should be calling ->setattr to do the truncation and hence
> follow normal convention for truncating blocks off an inode.
> However, even that appears to have thorns. e.g. in XFS we hold the
> iolock exclusively when we call block_write_begin(), but it is not
> held in all cases where ->setattr is currently called. Hence calling
> ->setattr from block_write_begin in this failure case will deadlock
> unless we also pass a "nolock" flag as well. XFS already
> supports this (e.g. see the XFS fallocate implementation) but no other
> filesystem does (some probably don't need to).
This paragraph in particular reminds me of an outstanding bug with
O_DIRECT and ext*. It isn't truncating partial allocations when a dio
fails with ENOSPC. This was noticed by a user who saw that fsck found
bocks outside i_size in the file that saw ENOSPC if they tried to
unmount and check the volume after the failed write.
So, whether we decide that failed writes should call setattr or
vmtruncate, we should also keep the generic O_DIRECT path in
consideration. Today it doesn't even try the supposed generic method of
calling vmtrunate().
- z
(Though I'm sure XFS' dio code already handles freeing blocks :))
next prev parent reply other threads:[~2008-04-29 17:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-29 10:06 correct use of vmtruncate()? David Chinner
2008-04-29 17:10 ` Zach Brown [this message]
2008-04-29 21:52 ` David Chinner
2008-04-30 7:24 ` Aneesh Kumar K.V
2008-04-30 15:55 ` Zach Brown
2008-04-30 3:46 ` David Chinner
2008-04-30 7:47 ` Aneesh Kumar K.V
2008-04-30 10:15 ` David Chinner
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=481756A3.20601@oracle.com \
--to=zach.brown@oracle.com \
--cc=dgc@sgi.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=xfs@oss.sgi.com \
/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;
as well as URLs for NNTP newsgroup(s).