[zfs-fuse] zfs-fuse stability with NFS and SAMBA

[Cozezien]

Hi all,

I'm currently running zfs-fuse 0.60 (compiled from source w/ debug=2)
on ubuntu 9.10 and having issues with sharing it over the network.
I've tried both NFS and SAMBA and they SEEM to behave quite
similarly.

My zpool came from an opensolaris machine (pool version 22). Not sure
if that makes a difference, but hopefully not.

For SAMBA I configure it like this:
[storage]
path = /storage
read only = no
guest only = yes
guest ok = yes


I can see my samba share and browse into the main directory. Once
there I try to go to a sub-directory and zfs-fuse will quit with a
message "aborted".

When I try to share the drive with nfs-kernel-server the same
behaviour happens. My /etc/export configuration goes as follows:

/storage *(rw,async,no_subtree_check,fsid=1)

Any ideas on what I may be doing wrong here? I've looked for other
topics like this, but I didn't have any luck with solving the problem.
Is there a way to get a more detailed error message?

Thanks!
Cozezien

--
To post to this group, send email to zfs-...@googlegroups.com
To visit our Web site, click on http://zfs-fuse.net/

[Cozezien]

Okie after a little bit of research. I'm actually using ZFS pool
version 16. I've tried an upgrade to 10.04 and used the zfs-fuse in
that repository and it behaves the same way.

Cozezien

[sgheeren]

Latest testing branch features ZFS sharenfs property. Probably a little underdocumented, but see http://zfs-fuse.net/news/nfs-auto-share-sharenfs-support-landed-in-unstable

I haven't gotten round to writing a newsflash to tell the world about the new and improved testing branch, but here is the appropriate group posting: http://groups.google.com/group/zfs-fuse/msg/d0d7158f24f6a777

Testing is ahead of official/master by 115 commits.
Testing is ahead of the 0.6.0 release (tag) by 336 commits.

Relative to 0.6.0 testing has (among others):

• non blocking zfs send/recv (enable local piping e.g.)
• pool version 23
• zpool split
• sharenfs support (with nfs-kernel-server)
  

• fix for 'dataset busy' on destroy
• kstat interface
• libumem merged from libumem upstream source
• PowerPC support! (tested on Debian PPC)
• Autoreplace support (replaced Solaris'es SMF features with configurable /etc/zfs/zfs_pool_alert script)
• Configurable stack size limits (by popular demand)
• Dynamically raise kernel mmaps limit for daemon proces
• Experimental waf build support (SCons is still the main mechanism)
  

• Many many upstream features and fixes merged from onnv-gate

If you want to have just sharenfs, have a look at my previous 'favourite' revision: 0c54eb8d4a1dbb5b4100ec6c80f282292b678c58

[Emmanuel Anne]

Excellent list of changes by the way ! :)

2010/5/9 sgheeren <sghe...@hotmail.com>:

--
zfs-fuse git repository :
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary

[Cozezien]

OK, I've installed the version with info below

commit 12d41f24e1765ad541a90c5f0ecf176e63aed2da
Merge: b79138c b50a9e2

However I still have the same behaviour. The NFS server is not
crashing - only the zfs-fuse portion.

I setup the share parameter: zfs set sharenfs='*:rw' and have this in
my /var/lib/nfs/etab:

/storage
*(rw,sync,wdelay,hide,nocrossmnt,secure,root_squash,no_all_squash,no_subtree_check,secure_locks,acl,fsid=1,anonuid=65534,anongid=65534)


Not sure if it'll help, but here's a short record of what I'm getting
when I attach GDB to zfs-fuse --no-daemon and it fails:

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffed434710 (LWP 1780)]
0x00007ffff6a87a75 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x00007ffff6a87a75 in raise () from /lib/libc.so.6
#1 0x00007ffff6a8b5c0 in abort () from /lib/libc.so.6
#2 0x0000000000473b2d in ?? ()
#3 0x0000000000473d0d in ?? ()
#4 0x0000000000473d4b in ?? ()
#5 0x0000000000473d7d in ?? ()
#6 0x0000000000407f31 in ?? ()
#7 0x0000000000408357 in ?? ()
#8 0x000000000041b2a9 in ?? ()
#9 0x000000000041f339 in ?? ()
#10 0x00007ffff7796a49 in ?? () from /lib/libfuse.so.2
#11 0x000000000041e1c7 in ?? ()
#12 0x00007ffff79be9ca in start_thread () from /lib/libpthread.so.0
#13 0x00007ffff6b3a69d in clone () from /lib/libc.so.6
#14 0x0000000000000000 in ?? ()

Thanks for your help,
Cozezien

On May 9, 10:58 am, sgheeren <sghee...@hotmail.com> wrote:
> Latest testing branch features ZFS sharenfs property. Probably a little

> underdocumented, but seehttp://zfs-fuse.net/news/nfs-auto-share-sharenfs-support-landed-in-un...

>
> I haven't gotten round to writing a newsflash to tell the world about
> the new and improved testing branch, but here is the appropriate group
> posting:http://groups.google.com/group/zfs-fuse/msg/d0d7158f24f6a777
>
> Testing is ahead of official/master by 115 commits.
> Testing is ahead of the 0.6.0 release (tag) by 336 commits.
>
> Relative to 0.6.0 testing has (among others):
>

>         * non blocking zfs send/recv (enable local piping e.g.)
>         * pool version 23
>         * zpool split
>         * sharenfs support (with nfs-kernel-server)
>
>         * fix for 'dataset busy' on destroy
>         * kstat interface
>         * libumem merged from libumem upstream source
>         * PowerPC support! (tested on Debian PPC)
>         * Autoreplace support (replaced Solaris'es SMF features with
>           configurable /etc/zfs/zfs_pool_alert script)
>         * Configurable stack size limits (by popular demand)
>         * Dynamically raise kernel mmaps limit for daemon proces
>         * Experimental waf build support (SCons is still the main mechanism)
>
>         * Many many upstream features and fixes merged from onnv-gate

[sgheeren]

I think Emmanuel will have more insight on this one.

Did you enter /storage into /var/lib/nfs/etab or did zfs do that using
exportfs? The latter should be the case. If you had it in there for some
other reason it might conflict. Notably, I think it is suspect that the
fsid=1 (I vaguely recall that Emmanuel generates ids using some largish
offset so as to minimize clashes.... it's been some while though).

The stack trace is not very helpful right away. The abort/raise combo I
associate with an assert trap. However, this is funny, because the rest
of the stack is suggestive of a debug=0 build while that would not have
asserts... Can you tell us what the debug=n setting was for this build?

Also you might want to issue 'thread apply all bt' next time around.
Obviously on a debug=2 build :)

[Emmanuel Anne]

It looks a lot like an acl problem : acls coming from opensolaris, not
handled by zfs-fuse, but still there internally.
It's frustrating because it can't be reproduced easily (need to setup
a pool in opensolaris first for that).
Anyway if someone can prepare a small packed image with this problem,
I still would be interested !
Anyway, try
zfs set aclinherit=discard
and
zfs set aclmode=discard
it should normally help.

2010/5/9 sgheeren <sghe...@hotmail.com>:

--
zfs-fuse git repository :
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary

[Cozezien]

Ya, I think you're right. I tried to access the ZFS pool from another
user account and it caused the same crash (root account works
perfectly though). looks like it's more of a user permissions problem
as opposed to dealing with NFS and samba. I tried setting discard for
aclinherit and aclmode, but it still behaves the same way. I'll try
see if there are other settings that might apply.

Cozezien

On May 10, 8:36 am, Emmanuel Anne <emmanuel.a...@gmail.com> wrote:
> It looks a lot like an acl problem : acls coming from opensolaris, not
> handled by zfs-fuse, but still there internally.
> It's frustrating because it can't be reproduced easily (need to setup
> a pool in opensolaris first for that).
> Anyway if someone can prepare a small packed image with this problem,
> I still would be interested !
> Anyway, try
> zfs set aclinherit=discard
> and
> zfs set aclmode=discard
> it should normally help.
>

> 2010/5/9 sgheeren <sghee...@hotmail.com>:

> > To visit our Web site, click onhttp://zfs-fuse.net/

[Cozezien]

Whoot. Ok did a bit more playing around / reading zfs docs.

When you set the aclinherit and aclmode values to discard you need to
run chmod xxx -R on the entire pool to remove any previous ACL's
already set.

Some initial testing w/ a different local user on the computer and
sharing it across the network hasn't crashed it yet.

Good call on the permissions ;)

Cozezien

[Emmanuel Anne]

Yeah but the chmod can be run only on opensolaris I guess... or maybe
by root on linux ?
Anyway good to know you fixed it.

2010/5/10 Cozezien <mat.he...@gmail.com>:

[Cozezien]

It was done with the root accnt on Linux.

On May 10, 4:37 pm, Emmanuel Anne <emmanuel.a...@gmail.com> wrote:
> Yeah but the chmod can be run only on opensolaris I guess... or maybe
> by root on linux ?
> Anyway good to know you fixed it.
>

> 2010/5/10 Cozezien <mat.heikk...@gmail.com>:

[Emmanuel Anne]

Ok, good to know then.
If you have time could you try this :
create a test image with dd :
dd if=/dev/zero of=image bs=100M count=1
create a pool on it
zpool create test /path-to-image
use opensolaris to put some bad acls on it (prefarablly on some files
created with touch so that they'll be small)
then once you are sure it crashes in linux, pack the image, and send
it to me by mail... (should be less than 2Mb since it's full of 0).

If you could do that it would be very useful, having a crash in this
case is not very convenient, even if we have a workaround...

2010/5/10 Cozezien <mat.he...@gmail.com>:

[Cozezien]

Sure, I'll need to do it when I get back from vacation (next weekend),
but I'll send it over :)

Cozezien

On May 10, 6:47 pm, Emmanuel Anne <emmanuel.a...@gmail.com> wrote:
> Ok, good to know then.
> If you have time could you try this :
> create a test image with dd :
> dd if=/dev/zero of=image bs=100M count=1
> create a pool on it
> zpool create test /path-to-image
> use opensolaris to put some bad acls on it (prefarablly on some files
> created with touch so that they'll be small)
> then once you are sure it crashes in linux, pack the image, and send
> it to me by mail... (should be less than 2Mb since it's full of 0).
>
> If you could do that it would be very useful, having a crash in this
> case is not very convenient, even if we have a workaround...
>

> 2010/5/10 Cozezien <mat.heikk...@gmail.com>:

> zfs-fuse git repository :...
>
> read more »

[sgheeren]

I added this reponse to bug 39: http://zfs-fuse.net/issues/39

Your problem is the usage of acls (90% certain). Emmanuel is currently
looking for someone to supply a test set as he doesn't currently have an
OSol box handy. If you care, you can submit a response to his open
request of the other day:

http://groups.google.com/gr[…]p;q=dd+acl#678eb707b70a13ae

Thx for submitting this. PS. the thread mentions a workaround, although
I understand you might not be in a position to remove the acls for this
purpose.

Seth

[Emmanuel Anne]

Still waiting for the image with bad acls inside, we might have a
better fix soon.

2010/5/14 sgheeren <sghe...@hotmail.com>: