[fuse-devel] changing file types on the fly

[Antonio SJ Musumeci]

I've a union filesystem and I'm looking at providing a bit of a hack in
order to (optionally) improve read speeds given Nikhilesh Reddy's
passthrough patch seems unlikely to get merged.

The idea is that getattr will lstat the underlying file and if it meets
some requirement (not a directory, readonly, etc.) then it modifies st_mode
to indicate its a symlink rather than it's original type and then on
readlink it can return the path to the original file.

The problem appears to be that if I change the type while the file is being
used it will cause the vfs to error out.

Is there any way, with the high level API, to work around this outside
keeping track of which files are currently in use? Any ideas on improving
performance otherwise?

[Jean-Pierre André]

Post by Antonio SJ Musumeci
I've a union filesystem and I'm looking at providing a bit of a hack in
order to (optionally) improve read speeds given Nikhilesh Reddy's
passthrough patch seems unlikely to get merged.
The idea is that getattr will lstat the underlying file and if it meets
some requirement (not a directory, readonly, etc.) then it modifies
st_mode to indicate its a symlink rather than it's original type and
then on readlink it can return the path to the original file.
The problem appears to be that if I change the type while the file is
being used it will cause the vfs to error out.

I have this same issue in ntfs-3g. The native ntfs
symlinks are void file files (or directories) with
a specific attribute (reparse data). So creating
such a symlink has to be done in two steps : first
creating the void file (or directory), then set the
attribute. As you noted, the vfs has a problem catching
up with the change.

Post by Antonio SJ Musumeci
Is there any way, with the high level API, to work around this outside
keeping track of which files are currently in use?

The only workaround I have found is to set the owner
of symlink again. Of course this has to be done by
the symlink originator, not by the file system, so
it is not transparent to the originator.

Post by Antonio SJ Musumeci
Any ideas on improving performance otherwise?

Jean-Pierre

[Miklos Szeredi]

On Wed, May 3, 2017 at 9:24 PM, Jean-Pierre André

Post by Antonio SJ Musumeci
I've a union filesystem and I'm looking at providing a bit of a hack in
order to (optionally) improve read speeds given Nikhilesh Reddy's
passthrough patch seems unlikely to get merged.
The idea is that getattr will lstat the underlying file and if it meets
some requirement (not a directory, readonly, etc.) then it modifies
st_mode to indicate its a symlink rather than it's original type and
then on readlink it can return the path to the original file.
The problem appears to be that if I change the type while the file is
being used it will cause the vfs to error out.

Let's merge the passthrough patch...

Thanks,
Miklos

[Miklos Szeredi]

On Fri, May 19, 2017 at 3:31 PM, Antonio SJ Musumeci

Last I checked it was kicked back to the author for tweaks but I don't
believe there was ever a follow up.
I'll reach out and see if there was progress.

Please do.

If somebody doesn't step up, I'll have a go sometime.

Just keep pestering (that symlink hack is a good one, I felt an urge
to do the passthrough now ;).

Thanks,
Miklos

[Mike Shal]

Post by Miklos Szeredi
On Fri, May 19, 2017 at 3:31 PM, Antonio SJ Musumeci

Last I checked it was kicked back to the author for tweaks but I don't
believe there was ever a follow up.
I'll reach out and see if there was progress.

Please do.
If somebody doesn't step up, I'll have a go sometime.
Just keep pestering (that symlink hack is a good one, I felt an urge
to do the passthrough now ;).

I tried reaching out to Nikhilesh several months ago to check in on
this, but I haven't heard back. I'm happy to help work on and test any
updates to his patches, though I don't quite understand the feedback
Jann Horn provided on his v5 patch[1] wrt file permissions. That was
the latest patch, to my knowledge.

-Mike
[1] https://lkml.org/lkml/2016/2/1/608