[lkml]   [2020]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: file metadata via fs API (was: [GIT PULL] Filesystem Information)
On Wed, Aug 12, 2020 at 3:54 PM David Howells <> wrote:
> Linus Torvalds <> 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
> from somewhere.
> 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 writemeta() and createmeta() and readdirmeta() and ...

The point is that generic operations already exist and no need to add
new, specialized ones to access metadata.


 \ /
  Last update: 2020-08-12 16:12    [W:0.737 / U:5.660 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site