[Lustre-devel] Flush on file close
Mitchell Erblich
erblichs at earthlink.net
Tue Apr 20 00:56:50 PDT 2010
Possible Suggestion,
NFS allows async writes and then commits.
I would almost suggest this..
As yes, close's are not expected to fail.
What would you do / should you do if a close failed?
Mitchell Erblich
On Apr 19, 2010, at 10:16 PM, Oleg Drokin wrote:
> Actually this is already being done. We do set AS_error (or something like that).
> There is only one exception where on eviction we forgot to implement this, I think.
>
> On Apr 19, 2010, at 10:34 PM, Andreas Dilger wrote:
>
>> One thing we can do to improve this situation a bit is to return any
>> previous write error codes at close time.
>>
>> Cheers, Andreas
>>
>> On 2010-04-19, at 12:30, Andrew Perepechko <Andrew.Perepechko at Sun.COM>
>> wrote:
>>
>>> Some applications expect non-zero errno on close() for any errors
>>> that may
>>> happen during flushing dirty cached data/metadata even though linux
>>> manual
>>> page for close(2) suggests that fsync(2) should be used prior to
>>> close(2) in
>>> order to detect problems like those.
>>>
>>> Since syncing may degrade performance to a large extent, what do you
>>> think is
>>> the best/most convenient/least intrusive way to switch to that
>>> behaviour?
>>> Should it be a mount option for the client or anything else?
>>>
>>> Andrew.
>>> _______________________________________________
>>> Lustre-devel mailing list
>>> Lustre-devel at lists.lustre.org
>>> http://lists.lustre.org/mailman/listinfo/lustre-devel
>> _______________________________________________
>> Lustre-devel mailing list
>> Lustre-devel at lists.lustre.org
>> http://lists.lustre.org/mailman/listinfo/lustre-devel
>
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel
More information about the lustre-devel
mailing list