[HELP] Connect go-fuse with NFS

[Archer F]

First:

#   ./loopback /root/nfsroot/ /root/ORIGIN

then set /root/nfsroot in /etc/exports:

/root/nfsroot              *(rw,sync,no_root_squash,fsid=1)

then mount nfs:

#   mount  localhost:/root/nfsroot mount_dir

everything goes right till now.

But when i entered mount_dir and type "ls", it shows:

ls: input/output error

 

I can do other things like touching/deleting a file, but I cannot open a directory.
My os : centos 5.5
Thanks for your reading

[Han-Wen Nienhuys]

NFS has a bunch of extra restrictions and requirements for
filesystems, which I have not bothered to look into.

Why do you want to mount a FUSE fs as NFS? It is more direct to have
the clients mount a FUSE FS that is backed by RPC.

--
Han-Wen Nienhuys
Google Engineering Belo Horizonte
han...@google.com

[Archer F]

We have the FUSE FS as a file server and we want it to be accessed via some protocols.
I have tried NFS and samba, both of them have some problems.

via samba  i cannot rename or delete a file.
When I want to delete a file in WINP client it got strange behaviour in logs:

mountstate.go:233: Dispatch: ACCESS, NodeId: 1. data: {x}
 mountstate.go:260: Serialize: ACCESS code: OK value:
 mountstate.go:233: Dispatch: GETATTR, NodeId: 1. data: {Fh 0}
 mountstate.go:260: Serialize: GETATTR code: OK value: {A1.000000000 &{1 4096 8 1336376912 1336376882 1336376882 147549414 463052486 463052486 16877 12 {0 0} 0 4096 0}}
 mountstate.go:233: Dispatch: LOOKUP, NodeId: 1. names: [1.txt] 6 bytes
 mountstate.go:260: Serialize: LOOKUP code: OK value: {410156720 E1.000000000 A1.000000000 &{410156720 0 0 1336376616 1336376616 1336376882 391464000 391464000 463052486 33188 1 {0 0} 0 4096 0}}
 mountstate.go:233: Dispatch: OPENDIR, NodeId: 1.
 mountstate.go:260: Serialize: OPENDIR code: OK value: {Fh 410919920 NONSEEK}
 mountstate.go:233: Dispatch: RELEASEDIR, NodeId: 1. data: {Fh 410919920 NONBLOCK,DIRECTORY,LARGEFILE,CLOEXEC  L0}
 mountstate.go:260: Serialize: RELEASEDIR code: OK value:
 mountstate.go:233: Dispatch: OPENDIR, NodeId: 1.
 mountstate.go:260: Serialize: OPENDIR code: OK value: {Fh 410920928 NONSEEK}
 mountstate.go:233: Dispatch: RELEASEDIR, NodeId: 1. data: {Fh 410920928 CLOEXEC,NONBLOCK,DIRECTORY,LARGEFILE  L0}
 mountstate.go:260: Serialize: RELEASEDIR code: OK value:
 mountstate.go:233: Dispatch: GETATTR, NodeId: 1. data: {Fh 0}
 mountstate.go:260: Serialize: GETATTR code: OK value: {A1.000000000 &{1 4096 8 1336376912 1336376882 1336376882 147549414 463052486 463052486 16877 12 {0 0} 0 4096 0}}
 mountstate.go:233: Dispatch: GETXATTR, NodeId: 1. names: [system.posix_acl_access] 24 bytes
 mountstate.go:260: Serialize: GETXATTR code: 61=no data available value:
 mountstate.go:233: Dispatch: GETXATTR, NodeId: 1. names: [system.posix_acl_default] 25 bytes
 mountstate.go:260: Serialize: GETXATTR code: 61=no data available value:
 mountstate.go:233: Dispatch: GETXATTR, NodeId: 410156720. names: [system.posix_acl_access] 24 bytes
 mountstate.go:260: Serialize: GETXATTR code: 61=no data available value:                                                              
 mountstate.go:233: Dispatch: GETXATTR, NodeId: 1. names: [system.posix_acl_access] 24 bytes                                           
 mountstate.go:260: Serialize: GETXATTR code: 61=no data available value:
 mountstate.go:233: Dispatch: GETXATTR, NodeId: 1. names: [system.posix_acl_default] 25 bytes
 mountstate.go:260: Serialize: GETXATTR code: 61=no data available value:
 mountstate.go:233: Dispatch: GETXATTR, NodeId: 410156720. names: [system.posix_acl_access] 24 bytes
 mountstate.go:260: Serialize: GETXATTR code: 61=no data available value:

[Brad Fitzpatrick]

The user-space NFS server in Linux imposes fewer (no?) restrictions on the filesystem, compared to the kernel-space NFS server.  Might be worth a shot.

But if Samba in user-space is likewise broken, I suspect some certain FUSE operation isn't being implemented or implement completely.  

[Archer F]

Thanks.
I traced my log when I access to FUSE FS via NFS, when I type

fly@LocalBox:~/mount_dir$ mkdir cccccccc
mkdir: cannot create directory `cccccccc': Input/output error

 

the log shows:

2012/05/07 19:50:40 get attr : cccccccc &{{1001 1001} 906}
2012/05/07 19:50:40 GetAttr failed: no such file or directory
2012/05/07 19:50:40 mkdir: cccccccc 509 &{{1001 1001} 906}
2012/05/07 19:50:40 get attr : cccccccc &{{1001 1001} 906}
2012/05/07 19:50:40 get attr :  &{{1001 1001} 906}
2012/05/07 19:50:40 getXAttr  system.posix_acl_default
2012/05/07 19:50:40 getXAttr ret: data:  code 2=no such file or directory

Why GetXAttr would be called using NFS when I make a directory. There're some similar problems using Samba which GetXAttr is called.

[Han-Wen Nienhuys]

On Mon, May 7, 2012 at 8:45 AM, Brad Fitzpatrick <brad...@golang.org> wrote:
> The user-space NFS server in Linux imposes fewer (no?) restrictions on the
> filesystem, compared to the kernel-space NFS server.  Might be worth a shot.

Do you have a link to detail the differences between both?

I remember that one of the things C-FUSE does is add entries for "."
and ".." to their readdir output. The other things is that they want
inode numbers to be stable forever.

> But if Samba in user-space is likewise broken, I suspect some certain FUSE
> operation isn't being implemented or implement completely.

[Han-Wen Nienhuys]

On Mon, May 7, 2012 at 8:58 AM, Archer F <darkte...@gmail.com> wrote:
> Thanks.
> I traced my log when I access to FUSE FS via NFS, when I type
>
>> fly@LocalBox:~/mount_dir$ mkdir cccccccc
>> mkdir: cannot create directory `cccccccc': Input/output error
>
>
> the log shows:
>>
>> 2012/05/07 19:50:40 get attr : cccccccc &{{1001 1001} 906}
>> 2012/05/07 19:50:40 GetAttr failed: no such file or directory
>> 2012/05/07 19:50:40 mkdir: cccccccc 509 &{{1001 1001} 906}
>> 2012/05/07 19:50:40 get attr : cccccccc &{{1001 1001} 906}
>> 2012/05/07 19:50:40 get attr :  &{{1001 1001} 906}
>> 2012/05/07 19:50:40 getXAttr  system.posix_acl_default
>> 2012/05/07 19:50:40 getXAttr ret: data:  code 2=no such file or directory
>
>
> Why GetXAttr would be called using NFS when I make a directory. There're
> some similar problems using Samba which GetXAttr is called.

XAttrs are used to implement ACL checking (notice the attribute names:
system.posix_acl_default). If Samba uses posix ACLs for permission
checking, that might explain it. One thing you can try, is to use
ENOSYS for the XAttr functions. This will the kernel to stop asking
for any XAttrs. The other option is to try to implement proper ACLs,
but I don't know how these ACLs should look like.

I'll try NFS on FUSE one of these days and let you know what I can find out.

[Archer F]

Thanks for your help.

[Han-Wen Nienhuys]

I have been tinkering with this for a bit, but I can't export my NFS share.  Do you have an idiot proof guide on how to do this on Fedora 17? Thanks! 

[hanwen@haring ~]$  cat /etc/exports

/mnt/fuse              *(rw,sync,no_root_squash,fsid=1)

[hanwen@haring ~]$ sudo  /etc/init.d/netfs restart

Restarting netfs (via systemctl):                          [  OK  ]

[hanwen@haring ~]$ sudo /sbin/mount.nfs -v localhost:/mnt/fuse /tmp/artmount.nfs: timeout set for Fri May 25 02:13:12 2012

mount.nfs: trying text-based options 'vers=4,addr=127.0.0.1,clientaddr=127.0.0.1'

mount.nfs: mount(2): Connection refused

Thanks for your reading

[Han-Wen Nienhuys]

Em sexta-feira, 4 de maio de 2012 07h02min44s UTC-3, Archer F escreveu:

First:

# ./loopback /root/nfsroot/ /root/ORIGIN

..

I've had success mounting a Go-FUSE loopback filesystem over NFS just now, including listing directories, creating and opening files. 

If you run loopback, you will probably want to use the new -allow-other option (or use MountOptions.AllowOther for whatever filesystem you are developing.)

You should keep in mind that for real filesystems, NFS mounts on the client are able to survive an NFS server crash. This means that the file ID numbers on the server (ie. the inode numbers) should be stable across mounts, which can only be done if the filesystem is backed by stable storage.

I've modified go-fuse to use random generation numbers, and added MountOptions.RememberInodes, so we will at least never reuse inode numbers which could lead to very awkward behavior, but depending on your intended application, more tweaks to go-fuse may be needed for it to really be supported.

What kind of FS do you want to export? Are you using NodeFileSystem or the path based FileSystem?