Hi again, > Message du 25/07/08 13:35 > De : "Sven Garly" <[EMAIL PROTECTED]> > A : "Jean-Pierre ANDRE" <[EMAIL PROTECTED]> > Copie à : [email protected] > Objet : Re: [ntfs-3g-devel] Question about ntfs_fuse_* functions > > > 2008/7/25 Jean-Pierre ANDRE <[EMAIL PROTECTED]>: > > That is a consequence of using the high-level fuse interface, > > for any action on a file you have to get its context from the > > file name. > > There is the fh field of the fuse_file_info struct for saving context > (or rather, a pointer to the context). >
I do not thing the fuse_file_info struct is related to a file, but rather to an "opening" of a file, which means it is not useful for keeping a reference to an inode copy. It could however be useful for keeping an inode number. However most of path to inode conversions come from getattr() with no fuse_file_info struct provided. > > > Do you mean you keep the inode open ? You may have problems with > > concurrent access to the file. > > That's one of the things that's been at the back of my mind - I've > improved performance but have I compromised data integrity? > > > > You could also get into problems > > after a power shortage. > > The approach taken only reduces the likelihood, it won't, of course, > remove the problem. This is what I meant. There is no journaling in ntfs-3g. > > I'm currently pondering whether I can get the best of both worlds by > keeping the inodes around but syncing them to disk if they're dirty. > I wonder whether it would be useful to cache a copy of inode description from the inode number (without preventing the dirty inode to be flushed to disk in order to get correct update times). I would think this is already cached at the physical layer. Regards Jean-Pierre ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
