Re: Streams support in Linux

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Aug 25, 2018 at 06:51:07AM -0700, Matthew Wilcox wrote:

> openat()
> To access a named stream, we need to be able to get a file descriptor for
> it.  The new openat() syscall seems like the best way to accompish this;
> specify a file descriptor, a new AT_NAMED_STREAM flag and a filename,
> and the last component of the filename will be treated as the name of
> the stream within the object.  This permits us to distinguish between
> a named stream on a directory and a file within a directory.

What do you do for access via /proc/*/fd/*, when descriptor is a sodding
stream?

> renameat()
> If olddirfd + oldpath refers to a stream then newdirfd + newpath must
> refer to a stream within the same parent object.  If that stream exists,
> it is removed.  If olddirfd + oldpath does not refer to a stream, then
> newdirfd + newpath must not refer to a stream.

And here the shit begins - what to do when parents have different dentries?
Directories can't have hardlinks; regular files very much can.

Where do dentries of these things belong, anyway?

> unlinkat()
> This is how you remove an individual named stream

Yeah... and what happens to access via other hardlinks to the same parent
file?

> unlink()
> Unlinking a file with named streams removes all named streams from that
> file and then unlinks the file.  Open streams will continue to exist in
> the filesystem until they are closed, just as unlinked files do.

Can they be looked up by openat() from such a starting point?

The only new part in that proposal is requesting explicit AT_... flag to
even get to those.  In effect, you are multiplexing a lot of syscalls
that way, which does, in theory, allow different locking scheme to be
used from the very beginning.  However, that doesn't take care of quite
a few other problems; a lot of code fundamentally assumes that ability
to have children mean having only one chain of ancestors.

And frankly, we already have one pile of garbage of that sort; what's the
benefit of adding another?  About the only difference between those and
xattrs is the ability to open them; is the resulting headache worth the
trouble, seeing that naive programs can't use that shit and somebody
arranging redirects for them can bloody well use pipe and stick around
feeding xattr contents into it...



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux