Hi S.,
On Mon, 2025-07-28 at 15:10 +0000, [email protected] wrote: > Hi, > > I'm writing FUSE fs's, and need a method for doing lookups for of > dentries and inodes. > To start with dentries, a FUSE lookup uses the parent inode ino (an > uint64_t) and the name. > > Now I've expirmented a lttle creating a key like: > > - first 8 bytes used by parent inode ino, left padded with zeros. > - rest the name of the entry > > like > > 00000001dexample > > which is the directory dexample in directory with ino 1. > (to make this work custom locking is required) > > It works, but is it a good idea to do? Or are there other methods > better? > > S.Bon It's notable that the LMDB DB key size is limited at compilation time (it can be changed), but the default is well above NAME_MAX+8, so you should be good, for a file name, and even attributes. Looks like this filesystem is squashfs-like in that it's pre-built and nothing would change afterwards, with potentially (file attributes, file data) as value corresponding to this (parent inode, ..., basename) key? I had posted here before about LMDB for filesystem indexing, which is rather similar, and got some feedback. For a more dynamic structure, I was not considering putting "dynamic" values in a key. Best regards, -- Jérôme
signature.asc
Description: This is a digitally signed message part
