Re: file metadata via fs API (was: [GIT PULL] Filesystem Information)

On Wed, Aug 12, 2020 at 5:08 PM Al Viro [off-list ref] wrote:

On Wed, Aug 12, 2020 at 04:46:20PM +0200, Miklos Szeredi wrote:

quoted

quoted

"Can those suckers be passed to
...at() as starting points?

No.

Lovely.  And what of fchdir() to those?

Not allowed.

Are they all non-directories?
Because the starting point of ...at() can be simulated that way...

quoted

quoted

 Can they be bound in namespace?

No.

quoted

Can something be bound *on* them?

No.

quoted

 What do they have for inodes
and what maintains their inumbers (and st_dev, while we are at
it)?

Irrelevant.  Can be some anon dev + shared inode.

The only attribute of an attribute that I can think of that makes
sense would be st_size, but even that is probably unimportant.

quoted

 Can _they_ have secondaries like that (sensu Swift)?

Reference?

http://www.online-literature.com/swift/3515/
        So, naturalists observe, a flea
        Has smaller fleas that on him prey;
        And these have smaller still to bite 'em,
        And so proceed ad infinitum.
of course ;-)
IOW, can the things in those trees have secondary trees on them, etc.?
Not "will they have it in your originally intended use?" - "do we need
the architecture of the entire thing to be capable to deal with that?"

No.

quoted

quoted

Is that a flat space, or can they be directories?"

Yes it has a directory tree.   But you can't mkdir, rename, link,
symlink, etc on anything in there.

That kills the "shared inode" part - you'll get deadlocks from
hell that way.

No.  The shared inode is not for lookup, just for the open file.

 "Can't mkdir" doesn't save you from that.  BTW,
what of unlink()?  If the tree shape is not a hardwired constant,
you get to decide how it's initially populated...

Next: what will that tree be attached to?  As in, "what's the parent
of its root"?  And while we are at it, what will be the struct mount
used with those - same as the original file, something different
attached to it, something created on the fly for each pathwalk and
lazy-umounted?  And see above re fchdir() - if they can be directories,
it's very much in the game.

Why does it have to have a struct mount?  It does not have to use
dentry/mount based path lookup.

Thanks,
Miklos