On 6/4/21 11:13 AM, Max Reitz wrote: > Hi, > > This is the C virtiofsd equivalent to > https://gitlab.com/virtio-fs/virtiofsd-rs/-/merge_requests/26. As such, > the summary is pretty much the same: > > Storing an O_PATH file descriptor in every lo_inode object means we have > a lot of FDs open, which is sometimes bad. This series adds an option > (-o inode_file_handles) that will make virtiofsd attempt to generate a > file handle for new inodes and store that instead of an FD. When an FD > is needed for a given inode, we open the handle. > > To accomplish this, lo_inode.fd is should not be accessed directly > anymore, but only through helper functions (mainly lo_inode_fd() and > lo_inode_open()). A TempFd object is added to hide the difference > between FDs that are bound to the lo_inode object (and so need not be > closed after use) and temporary FDs from open_by_handle_at() (which do > need to be closed after use). > > To prevent the problem I spent a long time talking about (if we don’t > have an FD open for every inode, the inode can be deleted, its ID > reused, and then the lookup in lo_data.inodes will find the old deleted > inode), patch 7 adds a second hash table lo_data.inodes_by_handle that > maps file handles to lo_inode objects. (Because file handles include a > generation ID, so we can discern between the old and the new inode.) > > Patch 9 is completely optional, but I just really felt compelled to > write it. > > > Max Reitz (9): > virtiofsd: Add TempFd structure > virtiofsd: Use lo_inode_open() instead of openat() > virtiofsd: Add lo_inode_fd() helper > virtiofsd: Let lo_fd() return a TempFd > virtiofsd: Let lo_inode_open() return a TempFd > virtiofsd: Add lo_inode.fhandle > virtiofsd: Add inodes_by_handle hash table > virtiofsd: Optionally fill lo_inode.fhandle > virtiofsd: Add lazy lo_do_find() > > tools/virtiofsd/helper.c | 3 + > tools/virtiofsd/passthrough_ll.c | 809 +++++++++++++++++++++----- > tools/virtiofsd/passthrough_seccomp.c | 2 + > 3 files changed, 667 insertions(+), 147 deletions(-) >
For the series: Reviewed-by: Connor Kuehl <cku...@redhat.com>