Problem with symlinks (fuse-nfs)?

[hexas...@gmail.com]

Hello,
I compiled libnfs from last sources and tested it on my machine (last ubuntu 64bit). Compilation is okay.

I setup a local NFS export:
/home/test  127.0.0.1(rw,sync,no_subtree_check)

Mounting it works:
./rfuse-nfs -n nfs://127.0.0.1/home/test -m ./fuse
(rfuse-nfs is just a wrapper for LD_LIBRARY_PATH as I just installed libnfs localy).

And it failed to show me symlinks:
$ ls -l ./fuse/
total 8
-rwx------ 1 hexasoft root 7 juil. 26 16:38 titi
-rw-r--r-- 1 hexasoft root 0 juil. 26 16:38 toto
-rwx------ 1 hexasoft root 7 juil. 26 16:38 tutu

Whereas performing the same on ./mnt with is a regular NFS mount of the same export I have:
$ ls -l ./mnt
total 4
-rwx------ 1 hexasoft root 7 juil. 26 16:38 titi
-rw-r--r-- 1 hexasoft root 0 juil. 26 16:38 toto
lrwxrwxrwx 1 root     root 4 juil. 26 16:38 tutu -> titi

Differences are the "total" (8 for fuse, 4 for NFS), and of course file 'tutu' which is dereferenced instead of being seen as a symlink.
Dumping the st_mode from fuse_nfs_getattr() shows st_mode=0100700, so the 700 mode of 'titi' and th 100000 for "regular file".

Is there any tunning to don't follows symlinks? Is it related to the fact that my NFS server handles NFSv4 by default as seen here:
$ mount -t nfs 127.0.0.1:/home/test ./mnt/
$ grep mnt /proc/mounts
127.0.0.1:/home/test /home/hexasoft/Code/FUSE/mnt nfs4 rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.0.1 0 0


At last when fuse-nfs is used I can see it in /proc/mounts:
fuse-nfs /home/hexasoft/Code/FUSE/fuse fuse.fuse-nfs rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions 0 0
but it don't appear in 'df' command.

Thanks for any help.

Regards,
--
Hexasoft

[hexas...@gmail.com]

Oups sorry! Due to the old version of libnfs I had on my system I replaced in fuse-nfs.c the call to nfs_lstat64() by nfs_stat64().
Now I'm using the recent lib I replaced it and it works fine!

Sorry for the noise.

The only remaining point is the mount not shown from 'df' command.

Regards,
--
Hexasoft

[ronnie sahlberg]

On Tue, Jul 26, 2016 at 9:36 AM, <hexas...@gmail.com> wrote:
> Oups sorry! Due to the old version of libnfs I had on my system I replaced
> in fuse-nfs.c the call to nfs_lstat64() by nfs_stat64().
> Now I'm using the recent lib I replaced it and it works fine!
>
> Sorry for the noise.

No worries.

>
> The only remaining point is the mount not shown from 'df' command.

I think that is common to many, or maybe all, FUSE filesystems.
They show up in mount but not in df.


Speculation: It may be related to the fact that these filesystems are
special in the way that they usually are only visible to the user that
created the mount. I.e. other users can generally not access or see
another users fuse filesystem.

I don't know how to make them show up in df.

> --
> You received this message because you are subscribed to the Google Groups
> "libnfs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to libnfs+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[hexas...@gmail.com]

Got it!

By strace-ing 'df' I found that it performs a statfs() call, which is not defined in fuse-nfs.c.
I added the following function in fuse-nfs.c (sorry not a diff):
static int fuse_nfs_statfs(const char *path, struct statvfs* stbuf)
{
  int ret = 0;
  struct statvfs svfs;

  ret = nfs_statvfs(nfs, path, &svfs);
 
  stbuf->f_bsize      = svfs.f_bsize;
  stbuf->f_frsize     = svfs.f_frsize;
  stbuf->f_fsid       = svfs.f_fsid;
  stbuf->f_flag       = svfs.f_flag;
  stbuf->f_namemax    = svfs.f_namemax;
  stbuf->f_blocks     = svfs.f_blocks;
  stbuf->f_bfree      = svfs.f_bfree;
  stbuf->f_bavail     = svfs.f_bavail;
  stbuf->f_files      = svfs.f_files;
  stbuf->f_ffree      = svfs.f_ffree;
  stbuf->f_favail     = svfs.f_favail;

  return ret;
}

And I referenced it in the 'fuse_operations' struct:
    .statfs   = fuse_nfs_statfs,

Running it and then calling 'df' gives me:
fuse-nfs                  204738328 188125508    6189680  97% /home/hexasoft/Code/FUSE/fuse

I'm right now trying to tweak the run-time exe-name in order to display the mount target rather than the 'fuse-nfs' binary name.
It is not the /proc/<pid>/comm, not the argv[] table (changed using execvp()), so I'm looking at the 'df' code in order to find what to change to display something like:
nfs://127.0.0.1/my/mount/point 204738328 188125508    6189680  97% /home/hexasoft/Code/FUSE/fuse

Will keep you informed about that.

Thanks.

--
Hexasoft


On Tuesday, July 26, 2016 at 6:18:29 PM UTC+2, hexas...@gmail.com wrote:

[hexas...@gmail.com]

Got it (again :))!

You have to use FUSE option 'fsname=NAME'.
I patched fuse-nfs.c to add:
    char buffer[1024];
in the declaration part of main().
I also added:
  // add FS type to 'url'
  sprintf(buffer, "-ofsname=%s", url);
  fuse_nfs_argv[fuse_nfs_argc++] = buffer;
just before
    nfs = nfs_init_context();
so after parameters checking but before initializing stuff.

Performing a df now looks like (including my previous change):
nfs://127.0.0.1/home/test   204738328 188318912    5996276  97% /home/hexasoft/Code/FUSE/fuse

We may of course build a different string based on 'url' (i.e. more similar to the 127.0.0.1:/home/test from a true NFS mount).

Please note that by default 'df' will only shows this mountpoint if '-a/--allow-other' is used apart for the one who performed the mount. Without this option (and apart for root of course) 'df' get a 'permission denied' when checking this mountpoint and will not treat it.

If you want to include my modifications in your code please feel free to use it with the licence you use for your code (GPL).


Note that I intend to work on it to build a failover NFS client on top of glusterFS NFS exports (for testing purpose) as at this time I still have memory leaks with the native glusterFS FUSE client.

I will post code if I manage to do something functionnal.

Regards,
--
Hexasoft

On Tuesday, July 26, 2016 at 6:18:29 PM UTC+2, hexas...@gmail.com wrote:

[hexas...@gmail.com]

Just a note:
I still got little differences beetween a pure NFS mount and a fuse-nfs mount on the same volume (first mounted on ./mnt/, second mounted on ./fuse/ at the same time):
127.0.0.1:/home/test        204738560 188318720    5996544  97% /home/hexasoft/Code/FUSE/mnt
nfs://127.0.0.1/home/test   204738328 188318988    5996200  97% /home/hexasoft/Code/FUSE/fuse
Apart for the "device" (127.0.0.1:/home/test) you can notice a little difference in "1K-blocks" and in "Used" (and so of course in "Available").
Don't know why, and not sure it is very important, but it may be checked in "pure NFS" and in "libnfs" source code. Because both correspond to the same exported directory and the same NFS server.

Regards,
--
Hexasoft


On Tuesday, July 26, 2016 at 6:18:29 PM UTC+2, hexas...@gmail.com wrote:

[hexas...@gmail.com]

Again me.
Using fuse-nfs I found that memory grows very fast so I checked around with valgrind and found lost memory related to 'opendir'.
After checking I saw that you choose just to handle 'fuse_opendir()' callback (performing everything in it) but in fuse_nfs_readdir() you do nfs_opendir() then nfs_readdir() but no nfs_closedir() at the end.
I added it just after the while() loop and it seems fine.

Regards,
--
Hexasoft

On Tuesday, July 26, 2016 at 6:18:29 PM UTC+2, hexas...@gmail.com wrote:

[ronnie sahlberg]

Merged, thanks!

[ronnie sahlberg]

Good stuff! Thanks, I have added these changes.