[Top] [All Lists]

Re: [PATCH] xfs: return FIEMAP_EXTENT_UNKNOWN for delayed allocation ext

To: Ben Myers <bpm@xxxxxxx>
Subject: Re: [PATCH] xfs: return FIEMAP_EXTENT_UNKNOWN for delayed allocation extent
From: Jeff Liu <jeff.liu@xxxxxxxxxx>
Date: Tue, 18 Jun 2013 10:25:58 +0800
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130617215353.GF20932@xxxxxxx>
References: <51B08D71.7090404@xxxxxxxxxx> <20130617215353.GF20932@xxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1
Hi Ben,
On 06/18/2013 05:53 AM, Ben Myers wrote:

> Hey Jeff,
> On Thu, Jun 06, 2013 at 06:24:01AM -0700, Jeff Liu wrote:
>> From: Jie Liu <jeff.liu@xxxxxxxxxx>
>> For FIEMAP ioctl(2), if an extent is in delayed allocation
>> state, we need to return the FIEMAP_EXTENT_UNKNOWN flag except
>> the FIEMAP_EXTENT_DELALLOC because its data location is unknown.
>> Signed-off-by: Jie Liu <jeff.liu@xxxxxxxxxx>
> Looks fine.  Is there an email thread I can reference?

I can't found an email thread to verify that, but according to
the specification of fiemap interface in kernel doc:

The location of this extent is currently unknown. This may indicate
the data is stored on an inaccessible volume or that no storage has
been allocated for the file yet.

  - This will also set FIEMAP_EXTENT_UNKNOWN. 
    ^^^^^ <-- so the unknown flags should be set as well.

Delayed allocation - while there is data for this extent, its
physical location has not been allocated yet.

Also, Btrfs did it.


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