Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> writes: > On Thu, 2011-10-20 at 16:37 -0400, Nikolaus Rath wrote: >> "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). > > The filehandle is between 32 (NFSv2) and 128(NFSv4) bytes long. How long > do you expect it to take you to create+destroy between 2^256 and 2^1024 > inodes? I'm guessing that we'll all be long dead and the universe will > have undergone heat death before that happens... Please stop assuming that I'm stupid or haven't thought about the problem at all. The bottleneck is not the length of the NFS file handle, but the length of the inode and generation number (both of which are restricted to 32bit by FUSE) together with the requirement that not only both of them together need to be unique forever, but the inode also needs to be unique at any given instant (so they cannot be trivially combined to form a 64bit value). 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
