[Top] [All Lists]

Re: correct use of vmtruncate()?

To: Zach Brown <zach.brown@xxxxxxxxxx>
Subject: Re: correct use of vmtruncate()?
From: "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx>
Date: Wed, 30 Apr 2008 12:54:57 +0530
Cc: David Chinner <dgc@xxxxxxx>, linux-fsdevel <linux-fsdevel@xxxxxxxxxxxxxxx>, linux-mm <linux-mm@xxxxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <481756A3.20601@oracle.com>
References: <20080429100601.GO108924158@sgi.com> <481756A3.20601@oracle.com>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.17+20080114 (2008-01-14)
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


<Prev in Thread] Current Thread [Next in Thread>