From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Zach Brown <zach.brown@oracle.com>
Cc: David Chinner <dgc@sgi.com>,
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: Wed, 30 Apr 2008 12:54:57 +0530 [thread overview]
Message-ID: <20080430072457.GB7791@skywalker> (raw)
In-Reply-To: <481756A3.20601@oracle.com>
On Tue, Apr 29, 2008 at 10:10:59AM -0700, Zach Brown wrote:
>
> > 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.
This patch should be the fix I guess
http://lkml.org/lkml/2006/12/18/103
-aneesh
WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Zach Brown <zach.brown@oracle.com>
Cc: David Chinner <dgc@sgi.com>,
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: Wed, 30 Apr 2008 12:54:57 +0530 [thread overview]
Message-ID: <20080430072457.GB7791@skywalker> (raw)
In-Reply-To: <481756A3.20601@oracle.com>
On Tue, Apr 29, 2008 at 10:10:59AM -0700, Zach Brown wrote:
>
> > 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.
This patch should be the fix I guess
http://lkml.org/lkml/2006/12/18/103
-aneesh
--
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>
next prev parent reply other threads:[~2008-04-30 7:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-29 10:06 correct use of vmtruncate()? David Chinner
2008-04-29 10:06 ` David Chinner
2008-04-29 17:10 ` Zach Brown
2008-04-29 17:10 ` Zach Brown
2008-04-29 21:52 ` David Chinner
2008-04-29 21:52 ` David Chinner
2008-04-30 7:24 ` Aneesh Kumar K.V [this message]
2008-04-30 7:24 ` Aneesh Kumar K.V
2008-04-30 15:55 ` Zach Brown
2008-04-30 15:55 ` Zach Brown
2008-04-30 3:46 ` David Chinner
2008-04-30 3:46 ` David Chinner
2008-04-30 7:47 ` Aneesh Kumar K.V
2008-04-30 7:47 ` Aneesh Kumar K.V
2008-04-30 10:15 ` David Chinner
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=20080430072457.GB7791@skywalker \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=dgc@sgi.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=xfs@oss.sgi.com \
--cc=zach.brown@oracle.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 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.