On Mon, Aug 31, 2020 at 12:02:56PM -0600, Andreas Dilger wrote: > On Aug 31, 2020, at 7:23 AM, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > > > On Mon, Aug 31, 2020 at 01:51:20PM +0200, Miklos Szeredi wrote: > >> On Mon, Aug 31, 2020 at 1:37 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > >> > >>> As I said to Dave, you and I have a strong difference of opinion here. > >>> I think that what you are proposing is madness. You're making it too > >>> flexible which comes with too much opportunity for abuse. > >> > >> Such as? > > > > One proposal I saw earlier in this thread was to do something like > > $ runalt /path/to/file ls > > which would open_alt() /path/to/file, fchdir to it and run ls inside it. > > That's just crazy. > > > >>> I just want > >>> to see alternate data streams for the same filename in order to support > >>> existing use cases. You seem to be able to want to create an entire > >>> new world inside a file, and that's just too confusing. > >> > >> To whom? I'm sure users of ancient systems with a flat directory > >> found directory trees very confusing. Yet it turned out that the > >> hierarchical system beat the heck out of the flat one. > > > > Which doesn't mean that multiple semi-hidden hierarchies are going to > > be better than one visible hierarchy. > > I can see the use of ADS for "additional information" about a single file > (e.g. verity Merkle tree with checksums of the file data) that are too big > to put into an xattr and/or need random updates. However, I don't see the > benefits of attaching a whole arbitrary set of files to a single filename. > > If people want a whole hierarchy of directories contained within a single > file, why not use a container (e.g. ext4 filesystem image) to hold all of > that? That allows an arbitrary group of files/directories/permissions to > be applied to a tree of files, but the container can be copied or removed > atomically as needed? > > Using a filesystem image as the container is (IMHO) preferable to using a > tarball or similar, because it can be randomly updated after creation, and > already has all of the semantics needed. Yup, that's pretty much the premise behind the XFS subvolume stuff I was exploring a while back. The file user data fork contains a filesystem image, and the filesystem can mount them where-ever it wants and manipulates the internal state as if it's just another filesytem. It's essentially the equivalent of virtual LBA address space mapping layer above the block layer. And if your user data fork is capable of reflink and COW, then you have atomically snapshottable virtually mapped filesystem containers a.k.a. subvolumes..... > The main thing that is needed is some mechanism that users can access that > decides whether access to the image is as a file, or if processed should > automount the image and descend into the contained namespace. XFS used to have a IF_UUID inode type that was intended on Irix to be a filesystem referral indicator. Kinda like a symlink, but it just contained a UUID rather than a path. Traversing a IF_UUID inode in the path would result in calling out to userspace to find the filesystem with that UUID and automounting it in place, then it would restart the path resolution and walk directly into the filesystem that got mounted... CHeers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
