mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jan Harkes <jaharkes@cs.cmu.edu>
To: Ravikiran G Thirumalai <kiran@in.ibm.com>
Cc: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
	linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
	Kai Makisara <Kai.Makisara@metla.fi>,
	Willem Riede <osst@riede.org>,
	coda@cs.cmu.edu, Paul Mackerras <paulus@samba.org>
Subject: Re: [patch 0/4] Cleanup file_count usage
Date: Tue, 16 Nov 2004 17:56:58 -0500	[thread overview]
Message-ID: <20041116225658.GA1341@delft.aura.cs.cmu.edu> (raw)
In-Reply-To: <20041116135200.GA23257@impedimenta.in.ibm.com>

On Tue, Nov 16, 2004 at 07:22:00PM +0530, Ravikiran G Thirumalai wrote:
> What remains:
> 1. Hack to return error code to user space at last close through file_count
>    check at the driver's flush routine.  This hack is used in scsi/st.c,
>    scsi/osst.c and coda/file.c to return error code through .flush() 
>    (Although it is doubtful if applications check for error during close(2)).
>    Kai has a patch to cleanup scsi/st.c.  I will make patches to move last 
>    close code from .flush() to .release() in the coda filesystem if no one 
>    objects to it.  Not sure if you can do anything on errors at close...

That won't work, in fops_release it is far too late to pass error codes
back to the application that called close(2).

In fact Coda used to only have a CODA_CLOSE upcall in coda_release until
users noticed that they never got an error return when the final write
to the servers failed. The only solution was to split the store and
release functionality of CODA_CLOSE so that we can perform the writeback
to the servers during the fops_flush operation (CODA_SYNC) and release
the last reference to the object during fops_release (CODA_RELEASE). If
either of these upcalls fails we fall back on the old behaviour.

People who write application with Coda in mind actually do check for
errors at close, it is the only time that we can actually generate any
errors as individual writes are not visible to the cache manager.

Do you have a link to the original discussion, what problem are we
trying to solve here?

Jan

  parent reply	other threads:[~2004-11-16 23:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-16 13:52 Ravikiran G Thirumalai
2004-11-16 13:57 ` [patch 1/4] Cleanup file_count usage: Bad usage at some .open, .release Ravikiran G Thirumalai
2004-11-16 14:03 ` [patch 2/4] Cleanup file_count usage: Error/debug messages on f_count reads Ravikiran G Thirumalai
2004-11-16 14:06 ` [patch 3/4] Cleanup file_count usage: Redundant check based on file_count Ravikiran G Thirumalai
2004-11-16 14:11 ` [patch 4/4] Cleanup file_count usage: Avoid file_count usage for hugetlb nattach reporting Ravikiran G Thirumalai
2004-11-16 14:24   ` William Lee Irwin III
2004-11-16 22:31 ` [patch 0/4] Cleanup file_count usage Paul Mackerras
2004-11-17 16:50   ` Ravikiran G Thirumalai
2004-11-17 22:07     ` Paul Mackerras
2004-12-01  6:30       ` Ravikiran G Thirumalai
2004-11-16 22:56 ` Jan Harkes [this message]
2004-11-16 23:19   ` Jan Harkes
2004-11-17  0:57 ` Willem Riede

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=20041116225658.GA1341@delft.aura.cs.cmu.edu \
    --to=jaharkes@cs.cmu.edu \
    --cc=Kai.Makisara@metla.fi \
    --cc=akpm@osdl.org \
    --cc=coda@cs.cmu.edu \
    --cc=kiran@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=osst@riede.org \
    --cc=paulus@samba.org \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®