small files can result in an allocation size of 0 (zero)

[Jeremy Allison]

On Tue, Mar 25, 2014 at 05:15:54PM +0100, Bjoern Baumbach wrote:
> Hi list!
> 
> I have figured out that files, which are smaller than one block, can be
> stored in an inode on some filesystems. I've experienced that on GPFS.
> This results in a block size of 0 (zero).
> 
> Example:
> # echo "some bytes of text" > file.dat
> # stat file.dat
>   File: `file.dat'
>   Size: 19              Blocks: 0
> 
> In this case the smbd interprets an allocation size of zero. For clients
> this can mean, that a file is an empty sparse file and might not read
> any data.
> In particular we have seen Windows clients, which load their roaming
> profile, and create zero sized files (locally) instead of the expected
> small files (as on the server).
> 
> The gnu tar people had the same problem and fixed that. Here is one
> message of the thread with suggestions to fix that.
> http://lists.gnu.org/archive/html/bug-tar/2013-10/msg00044.html
> 
> We have a working hack for this, that fakes a positive allocation size
> for non-empty files. I've attached this for discussion to this mail.
> In my opinion the attached patch is a solution with less performance
> losses and have only a (maybe bad impact) to real empty sparse files.
> This SEEK_DATA / SEEK_HOLE feature, which is discussed on the gnu lists,
> is comparatively new, so this wouldn't work on all systems.
> 
> I would like to discuss the proper fix for this issue.

Great catch ! I wasn't aware of this filesystem
behaviour. Well done :-).

The key is when st_blocks == 0, but st_size != 0.

I think this patch is doing the exactly correct
thing here - it's returning a one block allocation
size.

It looks like for Windows semantics that is exactly
what is needed.

The only potential difference would be on a UNIX
extensions POSIX stat call. The problem here is
that we don't know when we're doing the VFS getalloc
call if it's a POSIX stat or not...

But I certainly think the patch is good enough to
go in as is for now. I'll discuss with SteveF
and Jeff the impact on POSIX stat calls this week
at the LinuxCollab summit.

Jeremy.