Page MenuHomeFreeBSD

Add fuse mount information to 'from'
AbandonedPublic

Authored by ali.abdallah_suse.com on Apr 27 2022, 8:51 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Apr 27, 2:34 PM
Unknown Object (File)
Fri, Apr 26, 11:39 PM
Unknown Object (File)
Fri, Apr 26, 11:39 PM
Unknown Object (File)
Fri, Apr 26, 9:46 PM
Unknown Object (File)
Mar 4 2024, 8:10 AM
Unknown Object (File)
Feb 20 2024, 1:35 AM
Unknown Object (File)
Jan 12 2024, 9:10 AM
Unknown Object (File)
Jan 8 2024, 4:27 AM
Subscribers
Restricted Owners Package

Details

Reviewers
None
Group Reviewers
Restricted Owners Package(Owns No Changed Paths)
Summary

Prior to this commit, mounting fusefs will only work when the 'from' mount option is /dev/fuse, with this commit additional information can be added, such as /dev/fuse:mount_specific_info (similar to NFS)

This introduces no functional changes, expect that df will show fuse daemon specific info instead of just /dev/fuse as filesystem. Since I'm working in porting webdav fuse filesystem to FreeBSD, I find it helpful to have df shows something like:

http://192.168.1.10/ 159G 95G 64G 60% /mnt/test
http://192.168.1.11/ 18G 7.4G 9.5G 44% /mnt/test1

instead of:

/dev/fuse 159G 95G 64G 60% /mnt/test
/dev/fuse 18G 7.4G 9.5G 44% /mnt/test1

If this gets accepted, I will work to add support for it to libfuse.

Test Plan

This should not break any existing fuse software, using from='/dev/fuse' will still work okay and can be tested with any already existing fuse port.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

This looks awesome! It bothers me too when I have 100 different "/dev/fuse" file systems mounted, and I can't simply umount /dev/fuse. Speaking of which, does umount http://192.168.1.10 work with your patch? Could you please add a test for that in tests/sys/fs/fusefs/destroy.cc and another general test for the new feature in tests/sys/fs/fusefs/mount.cc? I can help with that, if you show me example usage with nmount. Also, I notice the "suse.com" in your username. Should we record this work as "Sponsored by: SuSE" when we commit it? Finally, are any other operating systems compatible with this usage?

sys/fs/fuse/fuse_vfsops.c
362

Hmm. The part about 'fuse0' isn't really accurate. FreeBSD doesn't support secondary mounts, so this should just be "fuse".
Also, style(9) says that multiline comments should start and end with blanks, like this:

/*
 * `from' contains the device name (eg. /dev/fuse0); REQUIRED
 * /dev/fuse0:fuse_specific_mount_path is also accepted
 */
372

You can eliminate the malloc like this:

char *mntfromname;

mntfromname = strsep(fuse_spec, ":");
err = fuse_getdevice*fuse_spec, td, &fdev);
...
strlcpy(mnt->mnt_stat.f_mntfromname, mntfromname == NULL ? fuse_spec : mntfromname);
453

This fuse_spec is not the same thing as the fuse_spec up above. So you should use a different name for this variable.

This looks awesome! It bothers me too when I have 100 different "/dev/fuse" file systems mounted, and I can't simply umount /dev/fuse.

I came out with much better approach than this, we can just use the existing fsname= field (as it is the case for fuse on Linux, 1st field in mtab is fsname). That approach doesn't require any changes to existing userspace fuse programs. I think we can close this and continue on : https://reviews.freebsd.org/D35090

Also, I notice the "suse.com" in your username. Should we record this work as "Sponsored by: SuSE" when we commit it?

I use my suse mail when contributing to free software projects, I will confirm you whether to not to add Sponsored by: SUSE (BTW, SUSE instead of SuSE :))

Closing this as it is wrong, https://reviews.freebsd.org/D35090 is a much better and simpler approach.