From: Christopher H. <chr...@fr...> - 2012-05-29 23:19:09
Attachments:
signature.asc
|
I'm looking for some perspective / wisdom here. Suppose your FUSE-based file system is running, and something bad happens that prevents proper operation of the virtual file system. (E.g., suddenly you cannot open the /actual/ files that provide the data for your virtual file system - perhaps gremlins ate them or something.) Or maybe some strange file i/o error occurred, and you are afraid to do anything else because it might damage user data. Is it ever okay and sensible to exit your process? Or should you just return errors from every FUSE function as long as the file system cannot operate? If you do have to exit, is there a proper way to do it? (i.e., notifying fuse somehow.) Perhaps this is too generic a question. but maybe there are some general rules that are applicable...? -- frigidcode.com indicium.us |
From: Lucas C. V. R. <lu...@go...> - 2012-05-30 00:37:36
|
On Tue, May 29, 2012 at 8:23 PM, Christopher Howard <chr...@fr...> wrote: > I'm looking for some perspective / wisdom here. Suppose your FUSE-based > file system is running, and something bad happens that prevents proper > operation of the virtual file system. (E.g., suddenly you cannot open > the /actual/ files that provide the data for your virtual file system - > perhaps gremlins ate them or something.) Or maybe some strange file i/o > error occurred, and you are afraid to do anything else because it might > damage user data. Is it ever okay and sensible to exit your process? Or > should you just return errors from every FUSE function as long as the > file system cannot operate? If you do have to exit, is there a proper > way to do it? (i.e., notifying fuse somehow.) > > Perhaps this is too generic a question. but maybe there are some general > rules that are applicable...? An option is to return -EROFS ("Read-only file system") on new writes / creates, and to return -EIO to read operations on handles already acquired. That might be more acceptable than exiting the daemon and leaving the file system users with stale file handles. -- Lucas "If you're looking for a reason I've a reason to give: pleasure, little treasure" |
From: Han-Wen N. <ha...@gm...> - 2012-05-30 00:52:54
|
On Tue, May 29, 2012 at 9:37 PM, Lucas C. Villa Real <lu...@go...> wrote: > On Tue, May 29, 2012 at 8:23 PM, Christopher Howard > <chr...@fr...> wrote: >> I'm looking for some perspective / wisdom here. Suppose your FUSE-based >> file system is running, and something bad happens that prevents proper >> operation of the virtual file system. (E.g., suddenly you cannot open >> the /actual/ files that provide the data for your virtual file system - >> perhaps gremlins ate them or something.) Or maybe some strange file i/o >> error occurred, and you are afraid to do anything else because it might >> damage user data. Is it ever okay and sensible to exit your process? No, I don't think so, using the same logic that a device problems (hard disk failing), should not cause your kernel to crash. Of course, if you detect an internal inconsistency (ie. a programming error) in your program, it may be better to crash. -- Han-Wen Nienhuys - ha...@xs... - http://www.xs4all.nl/~hanwen |