[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