plan for a feature: fsync for assuring file size
azez at ufomechanic.net
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.
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.
* 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