plan for a feature: fsync for assuring file size

[Amin Azez]

* James Peach wrote, On 25/10/07 16:50:
> On Oct 25, 2007, at 2:54 AM, SER.RI-TIC - David Losada wrote:
>> What to do? fsync. Right now we fsync at every write, and the windows
>> clients get notified in time. But it's biting us performance-wise. So
>> I'd prefer to fsync only when necessary.. and that's what I will try to
>> accomplish in this module
> 
> The problem is choosing which write call to issue the fsync on. Ideally
> you would issue it on the last write before the close, but there's no
> way to predict when the close will happen. So I really think that you
> have 2 options - sync on every write, or sync periodically.


There's a few more options:

Do the sync-ing strategy only on certain file types.

Generally we want to make sure the space is available before a write in
case it is the last write, but without fsync.

Other choices:

Make use of fallocate() or posix_fallocate() to reserve "stride" sized
blocks, if the underlying system supports it.

http://lists.samba.org/archive/samba-technical/2007-July/054648.html
http://www.opengroup.org/onlinepubs/009695399/functions/posix_fallocate.html

I am hoping that fallocate protects against lack of quota.
Implementation notes "suggest" that it does but glibc fallbacks might not.

Simulate fallocate:

* Have an extra per-file field which holds the logical file length
because we will over-allocate the physical file on-disk by the "stride"
amount, and then truncate the file to it's real length on close.

* Have a per-file temporary "quota reserving" file, the same size as the
sync-stride. If the sync fails, delete the quota-reserving file and try
again, but then try to create a new one.

Sam