@b0rk OOoO those file handles are interesting. They're big! 64 bytes are twice as big than 256 bits! I wonder if you can do something clever like encode some data in that. If your library lets you have a custom "cache" for files.
@b0rk@reconbot If it's a git repository you're serving, presumably you could use the blob ID for the file handle? A SHA-1 hash is only 20 bytes in its binary form.
@b0rk@reconbot From what I recall, there is no representation of directories in Git, right? But there is a tree object that covers the whole commit and includes a list of blobs and their paths or something? Could you encode (tree{20}, offset{24}, blob{20}) maybe, where offset is the position of the particular instance of the blob in the tree?
@b0rk I just found that article! I suspect, looking at this structure, you'd want a file handle of (blob ID) for files, and (parent tree ID, tree ID) for directories, and potentially (commit ID, tree ID) for the top directory in a commit. This would get you close to the structure UNIX file systems tend to have: files don't really live in a particular directory, they could be referenced from lots of directories; NFS clients can continue to access them by handle even if that structure changes.
@b0rk That is, to answer your "I don’t understand how real NFS servers do this, maybe they just have a really big cache?" question: generally I would expect that they don't do caching like this at all, and also aren't actually that aware of the whole path of a file at any point, but rather expose basically some relatively static number that identifies the file system + the inode number (or similar), for both files and directories.
@jmc@b0rk This is indeed the case. The traditional contents of a NFS filehandle are the inode number (or some other equivalent filesystem internal ID for the object), some filesystem ID, and a 'generation count' so that if a file is deleted and its inode is reused, NFS filehandles for the old file are now invalid. NFS servers don't necessarily know the path to filesystem objects, so traditionally they require a filesystem that supports operations like '..' on arbitrary directories.
@cks@jmc it seems a bit weird because the client sort of knows the path to the filesystem objects and I feel like the client should be able to tell the server what path it wants. But I guess that isn't how it works.
@b0rk@cks@jmc Paths in Unix are a bit weird. Remember you can have hard links so there's multiple routes to a file; also you get things like someone can rename a directory above you, but since you've got it open (and know the inode?) you know which directory you're in, even if it's no longer path reachable - heck, some nasty person could have deleted the file completely but you have it open still. Getting network FSs to fit with that is [imperfect] magic.
@penguin42@b0rk@jmc Cursed NFSv3 knowledge: how does NFSv3 deal with people deleting an open file? The answer is it doesn't. If you delete the file on the same client, NFS actually renames it to '.nfs<jumble>' and then tries to remember to delete it later, when you close the file. If you delete the file on the server or another client, the client with it open gets 'bad filehandle' errors.
(I believe NFS v4 does better here, because it can have more knowledge of open files on clients.)
@cks@b0rk@jmc Yeh, those are 'entertaining' - there are horrible race conditions and things with them (e.g. try and delete a directory, those .nfs files had better have gone before you try deleting the directory). I also haven't figured NFSv4 out.
Add comment