smbd: reporting of allocation size

[Uri Simchoni]

Hi,

I've seen that small files are reported as taking at least 1MB.

On the extreme case, a sparse file which takes zero space, is also
reported as taking 1MB (the value of "allocation roundup size").

Even sparse files created via SMB (via a Windows application which does
FSCTL_SET_SPARSE, followed by SetFileInformationByHandle(handle,
FileEndOfFileInfo,...) to set file length, end up taking 4K and still
reported as taking 1MB.

Folder size in clients such as Windows Explorer or the du utility, is
affected (yes - du. On an SMB2 linux mount we do this rounding up too...)

On a Windows server, at least a totally sparse file is reported as
taking 0 bytes, and we don't see small files reported as taking 1MB.

This behavior is caused by two things, one historic, and one due to
specific file systems:

1. If the block count returned by stat is 0, and the file is not zero
size, it is assumed that the file takes one block. This seems to
originate on commit c35b31f4 and this samba-technical thread -
https://lists.samba.org/archive/samba-technical/2014-March/098655.html ,
and it looks file-system specific. At least on new Linux kernels, and
ext2/3/4/xfs, stat does not report zero block count on small files, even
though ext4 for example is reported to store data on the inode.

2. Anything is rounded up to "allocation roundup size" parameter that
defaults to 1MB - I believe this rounding up was initially introduced in
commit  22afba62c in 2001, then briefly removed and re-added in 2005,
haven't found the relevant discussion in both cases, but it's supposed
to be performance-related.

For the "don't report zero allocation", I intend to refactor the code so
that all the roundup is outside VFS, and remove this "don't report zero
allocation" by default. Specific file systems will be able to overridet
this (GPFS has its own VFS module anyway).

For the roundup thing - I'd like to understand the source of this. How
much we understood what was going on, and whether it's still required
today. If it's not required, we may change the default or remove it
completely.

Thanks,
Uri.