plan for a feature: fsync for assuring file size

[James Peach]

On Oct 25, 2007, at 9:55 AM, SER.RI-TIC - David Losada wrote:

> En/na James Peach ha escrit:
>>>
>>> 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.
> I have some other ideas to make this a bit more optimal.
>
> 1. maybe the module could check what kind of client is in the other  
> side
> of the wire. If can identify "well-behaving" clients (i.e. smbclient),
> no need to sync for them.

I think you'd find that this is a bit too fragile.

> 2. the module would intercept the "write" (and "pwrite") calls, and
> fsync just when the file size has grown as a result of the call. No
> quota errors will happen when files don't grow. This saves some  
> syncing,
> but not for the most common case: file copying from Windows clients.

This would help in some cases, but not if the file is sparse. You  
would need to use strict allocation.

> 3. Windows clients seem to make an allocation of space before actually
> copying the file. When this happens, the VFS layer is called via the
> "ftruncate" call. The module could intercept this call and take a note
> of what is the expected length of the file. When a write or pwrite
> writes the last expected byte in the file, the module would fsync it.

This would be an easy and useful option in the vfs_commit module.

> 4. could intercept the "close" VFS call and write to syslog any quota
> errors that arise at that moment... in case we have missed something.
>>
>>> Once I have written the module.. how I should submit it so the Samba
>>> team considers its inclusion? I don't think we are the only
>>> "Samba-over-NFS" guys in the world...
>>
>> Post a patch to the mailing list.
> I'll play with this idea and send the results to the mailing list.
> samba-technical, I assume.
>
> Do you think it would make sense to merge the functions I described as
> another option of the vfs_commit module?


--
James Peach | jpeach at samba.org