Re: XFS status update for January 2011

[Tao Ma <tm@tao.ma>]

On 02/15/2011 07:55 AM, Dave Chinner wrote:
> On Mon, Feb 14, 2011 at 08:20:18AM -0700, tm@tao.ma wrote:
>    
>> Hi Dave,
>>      
>>> On Mon, Feb 14, 2011 at 10:17:26AM +0800, Tao Ma wrote:
>>>        
>>>> Hi Christoph,
>>>> On 02/14/2011 02:42 AM, Christoph Hellwig wrote:
>>>>          
>>>>> On the 4th of January we saw the release of Linux 2.6.37, which
>>>>>            
>>>> contains a
>>>>          
>>>>> large XFS update:
>>>>>
>>>>>      67 files changed, 1424 insertions(+), 1524 deletions(-)
>>>>>
>>>>> User visible changes are the new XFS_IOC_ZERO_RANGE ioctl which allows
>>>>> to convert already allocated space into unwritten extents that return
>>>>> zeros on a read,
>>>>>            
>>>> would you mind describing some scenario that this ioctl can be used. I
>>>> am
>>>> just wondering whether ocfs2 can implement it as well.
>>>>          
>>> Zeroing a file without doing IO or having to punch out the blocks
>>> already allocated to the file.
>>>
>>> In this case, we had a couple of different people in cloud storage
>>> land asking for such functionality to optimise record deletion
>>> be avoiding disruption of their preallocated file layouts as a
>>> punch-then-preallocate operation does.
>>>        
>> Thanks for the info. yeah, ocfs2 is also used to host images in some cloud
>> computing environment. So It looks helpful for us too.
>>      
> Just to be clear, this optimisation isn't relevant for hosting VM
> images in a cloud compute environment - this was added for
> optimising the back end of distributed storage applications that
> hold tens of millions of records and tens of TB of data per back end
> storage host.
>
> Hosting VM images is largely static, especially if you are
> preallocating them - they never, ever get punched. Even if you are
> using thin provisioning semantics and punching TRIMmed ranges, you
> aren't converting the TRIMmed ranges back to preallocated state so
> you wouldn't be using this interface. Hence I don't see this as
> something that you would use in such an environment.
>
> The distributed storage applications that this was added for
> required atomic record deletes from the back end and the fastest and
> safest way to do that was to turn the record being deleted back into
> unwritten extents.  This allows that operation to be done atomically
> by the filesystem whilst providing simple recovery semantics to the
> application. The XFS_IOC_ZERO_RANGE ioctl simply prevents the
> fragmentation that this punch-then-preallocate operation was causing
> and allows the back end to scale to much larger record stores...
>    
aha, got it. thanks for the detailed explanation.

Regards,
Tao