Re: file metadata via fs API (was: [GIT PULL] Filesystem Information)
From: David Howells
Date: Wed Aug 12 2020 - 09:54:57 EST
Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> IOW, if you do something more along the lines of
> fd = open(""foo/bar", O_PATH);
> metadatafd = openat(fd, "metadataname", O_ALT);
> it might be workable.
What is it going to walk through? You need to end up with an inode and dentry
It sounds like this would have to open up a procfs-like magic filesystem, and
walk into it. But how would that actually work? Would you create a new
superblock each time you do this, labelled with the starting object (say the
dentry for "foo/bar" in this case), and then walk from the root?
An alternative, maybe, could be to make a new dentry type, say, and include it
in the superblock of the object being queried - and let the filesystems deal
with it. That would mean that non-dir dentries would then have virtual
children. You could then even use this to implement resource forks...
Another alternative would be to note O_ALT and then skip pathwalk entirely,
but just use the name as a key to the attribute, creating an anonfd to read
it. But then why use openat() at all? You could instead do:
metadatafd = openmeta(fd, "metadataname");
and save the page flag. You could even merge the two opens and do:
metadatafd = openmeta("foo/bar", "metadataname");
Why not even combine this with Miklos's readfile() idea:
readmeta(AT_FDCWD, "foo/bar", "metadataname", buf, sizeof(buf));
and we're now down to one syscall and no fds and you don't even need a magic
filesystem to make it work.
There's another consideration too: Paths are not unique handles to mounts.
It's entirely possible to have colocated mounts. We need to be able to query
all the mounts on a mountpoint.