On Fri, 2011-10-21 at 09:54 -0400, Nikolaus Rath wrote: > 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). No. The point is you don't need a generation number if you don't want to implement one... You can use any unique identifier + the inode number, and the unique identifier is only limited by the size of the filehandle. Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- 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
