Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
	Frank van der Linden <fllinden@amazon.com>,
	Dave Chinner <david@fromorbit.com>,
	Matthew Wilcox <willy@infradead.org>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Greg Kurz <groug@kaod.org>,
	linux-fsdevel@vger.kernel.org,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Miklos Szeredi <mszeredi@redhat.com>,
	Vivek Goyal <vgoyal@redhat.com>,
	Giuseppe Scrivano <gscrivan@redhat.com>,
	Daniel J Walsh <dwalsh@redhat.com>,
	Chirantan Ekbote <chirantan@chromium.org>
Subject: Re: file forks vs. xattr (was: xattr names for unprivileged stacking?)
Date: Thu, 27 Aug 2020 14:02:42 +0200	[thread overview]
Message-ID: <1803870.bTIpkxUbEX@silver> (raw)
In-Reply-To: <CAJfpegt9Pmj9k-qAaKxcBOjTNtV5XsTYa+C0s9Ui9W13R-dv8g@mail.gmail.com>

On Dienstag, 25. August 2020 17:32:15 CEST Miklos Szeredi wrote:
> On Tue, Aug 25, 2020 at 5:12 PM Christian Schoenebeck
> 
> <qemu_oss@crudebyte.com> wrote:
> > I can give you another argument which might be more convincing to you: say
> > you maintain a middleware lib that takes a path as argument somewhere,
> > and that lib now gets path="/foo//bar". How could that lib judge whether
> > it should a) eliminate the double slash, or rather b) it was really meant
> > to be fork "bar" of file "foo" and hence shall pass the string as-is to
> > underlying
> > framework(s)? Simply: It can't, as it requires knowledge from either upper
> > or lower end that the lib in the middle might not have.
> 
> Nobody needs to care, only the level that actually wants to handle the
> alternative namespace.  And then that level absolutely *must* call
> into a level that it knows does handle the alternative namespace.
> 
> Yeah, it's not going to suddenly start to  work by putting "foo//bar"
> into an open file dialogue or whatever.   That's not the point, adding
> that  new interface is to enable *new* functionality not to change
> existing functionality.  That's the point that people don't seem to
> get.

I think you are underestimating the negative impact an n-times-slash delimiter 
would introduce. Middleware functionalities rely on unumbiguous path name 
resolution for being able to transform pathes without asking another level how 
it shall a) parse and b) interpret individual components of a path.

It would not be as simple as saying, they are now broken, let's fix them. 
Because path transformations happen so often on all levels on any system, that 
if you'd introduce a dependency for that (i.e. a simple path transformation 
would need to ask e.g. a storage backend for help), then it would slow down 
overall performance tremendously, especially as such requests are typically 
non-deterministic.

E.g. it is very common for a middleware function to transform a path into a 
list, and "/a/b//c/d" would now be ambiguous:

    "/a/b//c/d" -> [ "a", "b", "c", "d" ]

    or

    "/a/b//c/d" -> [ "a", "b", [ "c", "d" ] ]

You can't simply pass either one option to the next level, because it would 
break behaviour:

    foreach (dir_entry in [ "a", "b", "c", "d" ]) {
        dirAction(dir_entry)
    }

is different than:

    foreach (dir_entry in [ "a", "b" ]) {
        dirAction(dir_entry)
        foreach (fork_entry in [ "c", "d" ]) {
            forkAction(fork_entry)
        }
    }

Hence that simple path transformation would need to ask for help to resolve 
the ambiguity, which might take anything between few microseconds up to 
several seconds, then multiply that duration with the common amount of 
individual path transformations involved in just a very simple task.

---

What I could imagine as delimiter instead; slash-caret:

    /var/foo.pdf/^/forkname

I also like Microsoft's colon pick, as it would make shell interactions more 
slick:

	/var/foo.pdf:forkname

However I am aware that the colon would probably be too drastic, as colons are 
often used to separate individual pathes in a list for instance.

> > > The most important thing, I think, is to not fragment the interface
> > > further.  So O_ALT should allow not just one application (like ADS)
> > > but should have a top level directory for selecting between the
> > > various data sources.
> > 
> > Well, that's what name spaces are for IMO. So you would probably reserve
> > some prefixes for system purposes, like it is already done for Linux
> > xattrs. Or do you see any advantage for adding a dedicated directory
> > layer in between instead?
> 
> You mean some reserved prefixes for ADS?  Bleh.
> 
> No, xattr is not the model we should be following.

Maybe. I am actually unresolved about that. As that fs meta info PR recently 
showed, there might be other future use cases for this interface that one 
probably cannot foresee today; and a dedicated toplevel directory to choose 
between them would also make the kernel internal bindings more clean. So you 
might have for instance:

	/var/foo.pdf/^/alt/forkname   # for common ADS (incl. macOS data forks)

	/var/foo.pdf/^/res/forkname   # for mapping macOS resource forks

	/var/foo.pdf/^/meta/forkname  # for accessing fs implementation info

Best regards,
Christian Schoenebeck



  reply	other threads:[~2020-08-27 12:04 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-28 10:55 xattr names for unprivileged stacking? Dr. David Alan Gilbert
2020-07-28 13:08 ` Greg Kurz
2020-07-28 13:55   ` Christian Schoenebeck
2020-08-04 11:28     ` Dr. David Alan Gilbert
2020-08-04 13:51       ` Christian Schoenebeck
2020-08-12 11:18         ` Dr. David Alan Gilbert
2020-08-12 13:34           ` Christian Schoenebeck
2020-08-12 14:33             ` Dr. David Alan Gilbert
2020-08-13  9:01               ` Christian Schoenebeck
2020-08-16 22:56                 ` Dave Chinner
2020-08-16 23:09                   ` Matthew Wilcox
2020-08-17  0:29                     ` Dave Chinner
2020-08-17 10:37                       ` file forks vs. xattr (was: xattr names for unprivileged stacking?) Christian Schoenebeck
2020-08-23 23:40                         ` Dave Chinner
2020-08-24 15:30                           ` Christian Schoenebeck
2020-08-24 20:01                             ` Miklos Szeredi
2020-08-24 21:26                             ` Frank van der Linden
2020-08-24 22:29                             ` Theodore Y. Ts'o
2020-08-25 15:12                               ` Christian Schoenebeck
2020-08-25 15:32                                 ` Miklos Szeredi
2020-08-27 12:02                                   ` Christian Schoenebeck [this message]
2020-08-27 12:25                                     ` Matthew Wilcox
2020-08-27 13:48                                       ` Christian Schoenebeck
2020-08-27 14:01                                         ` Matthew Wilcox
2020-08-27 14:23                                           ` Christian Schoenebeck
2020-08-27 14:25                                             ` Matthew Wilcox
2020-08-27 14:44                                             ` Al Viro
2020-08-27 16:29                                               ` Dr. David Alan Gilbert
2020-08-27 16:35                                                 ` Matthew Wilcox
2020-08-28  9:11                                                 ` Christian Schoenebeck
2020-08-28 14:46                                                   ` Theodore Y. Ts'o
2020-08-27 15:22                       ` xattr names for unprivileged stacking? Matthew Wilcox
2020-08-27 22:24                         ` Dave Chinner
2020-08-29 16:07                           ` Matthew Wilcox
2020-08-29 16:13                             ` Al Viro
2020-08-29 17:51                               ` Miklos Szeredi
2020-08-29 18:04                                 ` Al Viro
2020-08-29 18:22                                   ` Christian Schoenebeck
2020-08-29 19:13                                   ` Miklos Szeredi
2020-08-29 19:25                                     ` Al Viro
2020-08-30 19:05                                       ` Miklos Szeredi
2020-08-30 19:10                                         ` Matthew Wilcox
2020-08-31  7:34                                           ` Miklos Szeredi
2020-08-31 11:37                                             ` Matthew Wilcox
2020-08-31 11:51                                               ` Miklos Szeredi
2020-08-31 13:23                                                 ` Matthew Wilcox
2020-08-31 14:21                                                   ` Miklos Szeredi
2020-08-31 14:25                                                   ` Theodore Y. Ts'o
2020-08-31 14:45                                                     ` Matthew Wilcox
2020-08-31 14:49                                                       ` Miklos Szeredi
2020-09-01  3:34                                                     ` Dave Chinner
2020-09-01 14:52                                                       ` Theodore Y. Ts'o
2020-09-01 15:14                                                         ` Theodore Y. Ts'o
2020-09-02  5:19                                                           ` Dave Chinner
2020-08-31 18:02                                                   ` Andreas Dilger
2020-09-01  3:48                                                     ` Dave Chinner
2020-08-29 19:17                               ` Matthew Wilcox
2020-08-29 19:40                                 ` Al Viro
2020-08-29 20:12                                   ` Matthew Wilcox
2020-08-31 14:23                                     ` Theodore Y. Ts'o
2020-08-31 14:40                                       ` Matthew Wilcox
2020-08-31 16:11                                       ` Christian Schoenebeck

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=1803870.bTIpkxUbEX@silver \
    --to=qemu_oss@crudebyte.com \
    --cc=chirantan@chromium.org \
    --cc=david@fromorbit.com \
    --cc=dgilbert@redhat.com \
    --cc=dwalsh@redhat.com \
    --cc=fllinden@amazon.com \
    --cc=groug@kaod.org \
    --cc=gscrivan@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=mszeredi@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=tytso@mit.edu \
    --cc=vgoyal@redhat.com \
    --cc=willy@infradead.org \
    --subject='Re: file forks vs. xattr (was: xattr names for unprivileged stacking?)' \
    /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

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