From: Mitchell Erblich <erblichs@earthlink.net>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] Flush on file close
Date: Tue, 20 Apr 2010 00:56:50 -0700 [thread overview]
Message-ID: <72C27251-2B14-48FE-BDD0-8B5252C7957A@earthlink.net> (raw)
In-Reply-To: <32DB67DD-B971-408E-8CD7-6B10344D7576@oracle.com>
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@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
next prev parent reply other threads:[~2010-04-20 7:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-19 18:30 [Lustre-devel] Flush on file close Andrew Perepechko
2010-04-19 22:31 ` Oleg Drokin
2010-04-20 2:34 ` Andreas Dilger
2010-04-20 5:16 ` Oleg Drokin
2010-04-20 7:56 ` Mitchell Erblich [this message]
2010-04-20 19:46 ` Oleg Drokin
2010-04-20 19:57 ` Oleg Drokin
2010-04-21 21:04 ` Andreas Dilger
2010-04-22 5:15 ` Alexey Lyashkov
2010-04-20 4:04 ` Andreas Dilger
2010-04-20 20:27 ` Nicolas Williams
2010-04-20 20:43 ` Nicolas Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=72C27251-2B14-48FE-BDD0-8B5252C7957A@earthlink.net \
--to=erblichs@earthlink.net \
--cc=lustre-devel@lists.lustre.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.