plan for a feature: fsync for assuring file size

[James Peach]

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

>
>>
>> It's easy to write a VFS module that takes some kind of action when
>> one of the write calls returns a space or quota error. I'm not sure
>> how you would notify the user that something bad happened other than
>> by returning the error.
>>
> Yes, I will go the VFS module way (but the module will do a different
> thing than you described). I have seen you guys have designed a nice
> interface :)
>
> I think I didn't manage to get my point across. I'll explain the  
> problem
> again. Common sense is that when Samba issues a disk full error, the
> Windows client should propagate it to the user. This isn't so.
>
> Windows  *ignores* this error from Samba *when it comes as a reply  
> to a
> close() call*. It *does* notify the user when Samba issues the error  
> as
> a reply to a write() call.

This is very common behaviour for both Unix and Windows apps. NFS  
engineers will tell you "of course you check the return value from  
close", but there's really nothing you can do because the state of  
your file descriptor is unspecified at this point.

> Because the Linux NFS code defers quota error notification until a  
> close
> call is issued (or an fsync), a standard Samba configuration only
> discovers the error when it's closing the file. Samba doesn't try to
> close the file until the client has asked for it to be closed. But,  
> as I
> have said, Windows  ignores quota errors at that moment... so the user
> never gets a notice that his file never got really saved
>
> 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.

> 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 know it's not Samba misbehaviour. If windows behaved correctly  
>>> this
>>> would be a non issue... if there was a solution which wouldn't ask  
>>> me to
>>> patch all windows machines (some of them not under our control), or
>>> ditch the investment we have made, or significantly slow our Samba
>>> servers.. I would go for it. Yes, this thing I'm proposing is a
>>> workaround.
>>>
>>> I think I understand that maybe because of this you'd rather have  
>>> it in
>>> a module, not in core code.
>>
>> I don't think I understand exactly what you want to do :)
>>
> Thanks for your patience :)

Thanks for the explanation :)


--
James Peach | jpeach at samba.org