linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-fsdevel@vger.kernel.org, samba-technical@lists.samba.org,
	Eric Biggers <ebiggers@kernel.org>
Subject: Re: Streams support in Linux
Date: Sat, 25 Aug 2018 15:47:45 +0100	[thread overview]
Message-ID: <20180825144745.GQ6515@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20180825135107.GA12251@bombadil.infradead.org>

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...

  reply	other threads:[~2018-08-25 18:26 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-25 13:51 Streams support in Linux Matthew Wilcox
2018-08-25 14:47 ` Al Viro [this message]
2018-08-25 15:51   ` Matthew Wilcox
2018-08-25 18:00     ` Al Viro
2018-08-25 20:57       ` Matthew Wilcox
2018-08-25 22:36         ` Al Viro
2018-08-26  1:03           ` Steve French
2018-08-27 17:05             ` Jeremy Allison
2018-08-27 17:41               ` Jeremy Allison
2018-08-27 18:21               ` Matthew Wilcox
2018-08-27 18:45                 ` Al Viro
2018-08-27 19:06                 ` Jeremy Allison
2018-08-28  0:45                 ` Theodore Y. Ts'o
2018-08-28  1:07                   ` Steve French
2018-08-28 18:12                     ` Jeremy Allison
2018-08-28 18:32                       ` Steve French
2018-08-28 18:40                         ` Jeremy Allison
2018-08-28 19:43                           ` Steve French
2018-08-28 19:47                             ` Jeremy Allison
2018-08-28 20:43                               ` Steve French
2018-08-28 20:47                                 ` Jeremy Allison
2018-08-28 20:51                                   ` Steve French
2018-08-28 21:19                                   ` Stefan Metzmacher
2018-08-28 21:22                                     ` Jeremy Allison
2018-08-28 21:23                                     ` Steve French
2018-08-29  5:13                                       ` Ralph Böhme
2018-08-29 13:46                       ` Tom Talpey
2018-08-29 13:54                         ` Aurélien Aptel
2018-08-29 15:02                           ` Tom Talpey
2018-08-29 16:00                             ` Jeremy Allison
2018-08-29 15:59                         ` Jeremy Allison
2018-08-29 18:52                           ` Andreas Dilger
2018-08-26 20:30           ` Matthew Wilcox
2018-08-25 16:25 ` Theodore Y. Ts'o
2018-08-27 16:33   ` Jeremy Allison
2018-09-20  2:06 Shahbaz Youssefi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180825144745.GQ6515@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=ebiggers@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=samba-technical@lists.samba.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).