[Ocfs2-devel] [PATCH 1/1] ocfs2: return non-zero st_blocks for inline data

[John Haxby]

> On 1 Dec 2015, at 07:08, Junxiao Bi <junxiao.bi at oracle.com> wrote:
> 
> On 11/25/2015 05:07 AM, John Haxby wrote:
>> Some versions of tar assume that files with st_blocks == 0 do not
>> contain any data and will skip reading them entirely. See also
>> commit 9206c561554c ("ext4: return non-zero st_blocks for inline data").
>> 
>> Signed-off-by: John Haxby <john.haxby at oracle.com>
>> ---
>> fs/ocfs2/file.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>> 
>> diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c
>> index 0e5b451..d631279 100644
>> --- a/fs/ocfs2/file.c
>> +++ b/fs/ocfs2/file.c
>> @@ -1302,6 +1302,14 @@ int ocfs2_getattr(struct vfsmount *mnt,
>> 	}
>> 
>> 	generic_fillattr(inode, stat);
>> +	/*
>> +	 * If there is inline data in the inode, the inode will normally not
>> +	 * have data blocks allocated (it may have an external xattr block).
>> +	 * Report at least one sector for such files, so tools like tar, rsync,
>> +	 * others don't incorrectly think the file is completely sparse.
>> +	 */
>> +	if (unlikely(OCFS2_I(inode)->ip_dyn_features & OCFS2_INLINE_DATA_FL))
>> +		stat->blocks += (stat->size + 511)>>9;
> From filesystem side, looks reasonable that data block is 0 for
> inlined-data file. This is like a hack to filesystem to fix tools issue.
> Indeed tar-1.26-27 have been fixed to not think file with st_blocks == 0
> empty. But I am not sure why ext4 merge that fix.

It’s not just tar and it’s not just ext4.   Programmers not unreasonably assume that a file occupying zero blocks contains no data (where would you put it?)

ext4, btrfs and ntfs-3g all give inlined files a non-zero block size to avoid surprising programmers.   There’s nothing in Posix that says what stat’s st_blocks so in this case it’s right for the file systems in question to stick to the principle of least surprise.  In this case, it would be surprising if some small files suddenly started occupying no space while being non-empty.   It’s not as though it would be consistent: some small files would occupy space and some would not.  We want to present a consistent view of files to the user.  It’s not as though we’re breaking du either: it already tells lies :)

Does that make sense now?

jch


> 
> Thanks,
> Junxiao.
> 
>> 
>> 	/* We set the blksize from the cluster size for performance */
>> 	stat->blksize = osb->s_clustersize;

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/ocfs2-devel/attachments/20151201/327439b3/attachment.html