"J. Bruce Fields" <bfields@xxxxxxxxxxxx> writes: > On Thu, Oct 20, 2011 at 01:21:31PM -0400, Nikolaus Rath wrote: >> I'm working on a FUSE file system that stores file system metadata in an >> SQL database (http://code.google.com/p/s3ql/). Not having to keep track >> of inode generation numbers would keep the code much simpler, because I >> want to delete inode-rows from the SQL table when the last reference to >> the inode is deleted (so I can't keep track of the generation no). > > You can use current time, or a counter, or something, as the generation > number. With current time I'm screwed if the system clock doesn't have sufficiently fine granularity. With a counter, I either have to remember counter values per-inode even after the inode is deleted, or the global counter will overflow at some point (in which case I may just as well require unique inodes in the first place). >> Now I'll either have to make inodes unique (and run into trouble after >> 2^32 inodes have been used), or keep with the current scheme of >> randomizing new inodes (which keeps the probability of problems low >> enough but is ugly). > > With 2^32 inode numbers plus 2^32 generation numbers it should be > possible to work something out that doesn't require remembering every > old inode. Certainly. All I'm saying is that the code would be simpler if there was no need for generation numbers. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
