From: Nikolaus R. <Nik...@ra...> - 2011-12-07 14:14:38
|
Goswin von Brederlow <goswin-v-b-S0/GAf...@pu...> writes: >> @@ -193,18 +193,34 @@ >> /** >> * Forget about an inode >> * >> - * The nlookup parameter indicates the number of lookups >> - * previously performed on this inode. >> + * This function is called when the kernel removes an inode >> + * from its internal caches. >> + * >> + * In inode's lookup count increases by one for every call to >> + * fuse_reply_entry and fuse_reply_create. The nlookup >> + * parameter indicates by how much the lookup count should be >> + * decreased. >> + * >> + * Inodes with a non-zero lookup count may not be deleted or >> + * reassigned by the file system. It is expected that calls to >> + * unlink, rmdir and (when overwriting an existing file) >> + * rename only remove the directory entry and defer removal of >> + * the inode until the lookup count reaches zero. > > Again I don't think is a requirement. Filesystems that don't > track lookup/forget numbers do certainly not follow this and work just > fine. How about this: > > * Inodes with a non-zero lookup count may recieve request from > * the kernel even after calls to unlink, rmdir or (when > * overwriting an existing file) rename. Filesystems must handle > * such requests properly and it is recommended to defer removal > * of the inode until the lookup count reaches zero. Calls to > * unlink, remdir or rename will be followed closely by forget > * unless the file or directory is open, in which case the > * kernel issues forget only after the release or releasedir > * calls. > * > * Filesystems that do not defer removal of inodes should > * provide callbacks for open/opendir and release/releasedir and > * store the approriate information in the struct fuse_file_info > * to allow opened but deleted files /directories to function as > * expected. > > But maybe that goes to far for the header file and we should have a > doc/best-practices.txt file to describe this? I think the first paragraph is good for the header file. >> + * >> + * Mutable file systems therefore need to keep track of the >> + * lookup count for each inode. >> * >> - * If the filesystem implements inode lifetimes, it is recommended >> - * that inodes acquire a single reference on each lookup, and lose >> - * nlookup references on each forget. >> - * >> - * The filesystem may ignore forget calls, if the inodes don't >> - * need to have a limited lifetime. >> - * >> - * On unmount it is not guaranteed, that all referenced inodes >> - * will receive a forget message. >> + * Note that if a file system will be exported over NFS, its >> + * (inode, generation no) pairs need to be unique over the >> + * lifetime of the file system (rather than just the mount >> + * time). So if the file system reuses an inode after it has >> + * been deleted, it must assign a new, previously unused >> + * generation number to the inode at the same time. >> + * > > Does this belong to forget? Maybe this should be added to the struct > fuse_entry_param instead. How about this for here: Sounds good to me too. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C |