lkml.org 
[lkml]   [2020]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: file metadata via fs API (was: [GIT PULL] Filesystem Information)
On Tue, Aug 11, 2020 at 08:20:24AM -0700, 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.

I have thought we want to replace mountinfo to reduce overhead. If I
understand your idea than we will need openat()+read()+close() for
each attribute? Sounds like a pretty expensive interface.

The question is also how consistent results you get if you will read
information about the same mountpoint by multiple openat()+read()+close()
calls.

For example, by fsinfo(FSINFO_ATTR_MOUNT_TOPOLOGY) you get all
mountpoint propagation setting and relations by one syscall, with
your idea you will read parent, slave and flags by multiple read() and
without any lock. Sounds like you can get a mess if someone moves or
reconfigure the mountpoint or so.


openat(O_ALT) seems elegant at first glance, but it will be necessary to
provide a richer (complex) answers by read() to reduce overhead and
to make it more consistent for userspace.

It would be also nice to avoid some strings formatting and separators
like we use in the current mountinfo.

I can imagine multiple values separated by binary header (like we already
have for watch_notification, inotify, etc):

fd = openat(fd, "mountinfo", O_ALT);

sz = read(fd, buf, BUFSZ);
p = buf;

while (sz) {
struct alt_metadata *alt = (struct alt_metadata *) p;

char *varname = alt->name;
char *data = alt->data;
int len = alt->len;

sz -= len;
p += len;
}


Karel

--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com

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