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

[Bjoern Baumbach]

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.

Best regards,
Björn

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s3-enforce-a-positive-allocation_file_size.patch
Type: text/x-patch
Size: 1412 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140325/2897149b/attachment.bin>