plan for a feature: fsync for assuring file size

Amin Azez azez at
Fri Oct 26 10:43:02 GMT 2007

* 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.

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.


More information about the samba-technical mailing list