Messages in this thread Patch in this message | | | Date | Tue, 16 Nov 2004 18:19:35 -0500 | Subject | Re: [patch 0/4] Cleanup file_count usage | From | Jan Harkes <> |
| |
On Tue, Nov 16, 2004 at 05:56:58PM -0500, Jan Harkes wrote: > 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...
If this f_count/file_count cleanup really has to go in, instead of moving the Coda code from flush to release, use the attached patch which simply removes last_close semantics from the kernel. This way I'll have to deal with an upcall for every close, but I can try to track the open count in our userspace cachemanager and do the last writer thing up there.
I would rather take the performance hit than lose the possibility to return meaningful errors on close.
Jan
--- linux/fs/coda/file.c.orig 2004-11-16 18:03:17.000000000 -0500 +++ linux/fs/coda/file.c 2004-11-16 18:04:03.000000000 -0500 @@ -157,11 +157,6 @@ coda_vfs_stat.flush++; - /* last close semantics */ - fcnt = file_count(coda_file); - if (fcnt > 1) - goto out; - /* No need to make an upcall when we have not made any modifications * to the file */ if ((coda_file->f_flags & O_ACCMODE) == O_RDONLY) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |