Re: [patch 0/4] Cleanup file_count usage

From: Jan Harkes
Date: Tue Nov 16 2004 - 18:06:12 EST


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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/