From: Gerard J. C. <gj...@ci...> - 2006-08-10 23:33:12
|
So... is it possible to flag a flush that was triggered by a close? I assume that the VFS system will not optimize out the close triggered flush, even if a flush came down from user space just before the user space close. I think I can handle any IO after the initial close with a simple EPERM return. Due to the nature of the file system only one writer is permitted onto a volume at a time so all other "owners" of the file will probably just ignore their own close anyway. I could even reply 0 for all other flushes, any additional writes will get the old EPERM. Joshua J. Berry wrote: > This is discussed a bit in the FAQ. See > http://fuse.sourceforge.net/wiki/index.php/FAQ#API , particularly "Wouldn't > it be simpler if there were a single close() method?" . > > The short answer is, it's not possible because the Linux kernel isn't > designed that way. It's not possible for FUSE to know which close() call > from userspace triggered a given release(). > > On Thursday 10 August 2006 15:56, Gerard J. Cerchio wrote: > >> I am implementing a media independent archive file system in FUSE. >> >> According to the documentation in fuse.h, flush is not guaranteed to be >> called at any time in the write cycle and there is no way to >> discriminate a final flush from any intermediate one. >> >> I therefore must perform all my post write data integrity checks in the >> release call and return an error if the data is not verified on the >> media. In fact, I actually transfer all my data to the target media >> during the release. >> >> Whether or not the application checks the status of the close call is a >> controllable risk in the environments that the file system is going to >> be used. >> >> The problem is there is no processing of the release call's error return >> in the FUSE library system. In fact, the library call for do_release is >> declared a void. >> >> My question is "Does FUSE have a deep problem handling error returns >> from release or is this a trivial modification to the FUSE project?" >> >> It seemed to me that the solution required trivial changes in fuse.c: >> >> In the method do_release, change to return the error code >> In the method fuse_release pass the return code to reply_error. >> >> I have implemented the changes and now see error codes being passed to >> the debug trace. Alas, I do not see the error return being passed to >> the fclose in my little test program that does check error returns on >> release. >> >> Any one care to comment? Is this going to require changes to the kernel >> module? >> >> Gerard Cerchio >> >> > |