[Top] [All Lists]

Re: sparse file handling bug in XFS

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: sparse file handling bug in XFS
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 16 Jun 2011 16:08:07 -0500
Cc: Trammell Hudson <Trammell.Hudson@xxxxxxxxxxxx>, Sean Noonan <Sean.Noonan@xxxxxxxxxxxx>, Martin Bligh <Martin.Bligh@xxxxxxxxxxxx>, Ian Baum <Ian.Baum@xxxxxxxxxxxx>, Stephen Degler <Stephen.Degler@xxxxxxxxxxxx>, "'linux-xfs@xxxxxxxxxxx'" <linux-xfs@xxxxxxxxxxx>
In-reply-to: <20110616175743.GA20570@xxxxxxxxxxxxx>
References: <081DDE43F61F3D43929A181B477DCA95639B561F@xxxxxxxxxxxxxxxxxxxx> <4DFA2A76.6000104@xxxxxxxxxxx> <4DFA3E7D.4030408@xxxxxxxxxxx> <20110616175743.GA20570@xxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20110414 Thunderbird/3.1.10
On 6/16/11 12:57 PM, Christoph Hellwig wrote:
> On Thu, Jun 16, 2011 at 12:33:49PM -0500, Eric Sandeen wrote:
>> Actually this looks like it's a result of
>> 6e857567dbbfe14dd6cc3f7414671b047b1ff5c7 xfs: don't truncate prealloc from 
>> frequently accessed inodes
>> I thought Dave's patch from the "Re: drastic changes to allocsize semantics 
>> in or around 2.6.38?"
>> thread would fix it, but it doesn't seem to.  Here it is anyway ;)
> It should fix the thing about the preallocation staying when removing
> and recreating the file.  Keeping pre-allocate blocks around otherwise
> is a considered a feature.

It strikes me as odd that truncating & rewriting would lead to
different preallocation though .. I'll let Dave chime in.


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