Guenter Feldmann
2005-Dec-01 12:41 UTC
[zfs-discuss] zfs pool based on nfs files. possible?
We''re testing a bit around with zfs. Yesterday we created two files
(each was
1GB) and made a mirror out of it:
zpool create tpool mirror /test/vol1 /test/vol2
It worked fine, so we wanted to do the same with mounted files from an nfs2
Filesystem and got the following error:
zpool create pool2 mirror /test/nfs/host1/bigfile /test/nfs/host2/bigfile
internal error: unexpected error 27 at line 444 of ../common/libzfs_pool.c
Today we reproduced the error with nfs4 (to make sure it''s not a
nfs2-problem) and received:
internal error: unexpected error 13 at line 444 of ../common/libzfs_pool.c
Same line, different error-codes. To us it''s looking more like a bug
than a general
limit of zfs. Will it be possible to work with zfs in the way we tried it (so
what we found
is just a bug) or haven''t you planned scenarios like this?
-- Guenter
This message posted from opensolaris.org
On Thu, Dec 01, 2005 at 04:41:23AM -0800, Guenter Feldmann wrote:> We''re testing a bit around with zfs. Yesterday we created two files (each was > 1GB) and made a mirror out of it: > zpool create tpool mirror /test/vol1 /test/vol2 > It worked fine, so we wanted to do the same with mounted files from an nfs2 > Filesystem and got the following error: > > zpool create pool2 mirror /test/nfs/host1/bigfile /test/nfs/host2/bigfile > internal error: unexpected error 27 at line 444 of ../common/libzfs_pool.c > > Today we reproduced the error with nfs4 (to make sure it''s not a > nfs2-problem) and received: > > internal error: unexpected error 13 at line 444 of ../common/libzfs_pool.c > > Same line, different error-codes. To us it''s looking more like a bug than a general > limit of zfs. Will it be possible to work with zfs in the way we tried it (so what we found > is just a bug) or haven''t you planned scenarios like this?Yes, these are definitely bugs in the sense that ZFS shouldn''t die with ''internal error'' messages. Please file bugs via opensolaris.org. But the underlying causes look NFS-related, and no changes to ZFS can make them work. In the first case, NFS is returning EFBIG for some operation. I don''t know why; maybe kustarz can chime in. In the second case, you''re getting EACCES, presumably because root doesn''t have access to these files over NFS. We need to pretty-print this error code, but there''s nothing we can do about this case. I just created a pool over NFS and everything worked fine. I''m not sure what kind of performance you''ll get in this configuration, but it''s definitely possible to do. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
Guenter Feldmann
2005-Dec-01 19:18 UTC
[zfs-discuss] Re: zfs pool based on nfs files. possible?
> I just created a pool over NFS and everything worked > fine. I''m not sure > what kind of performance you''ll get in this > configuration, but it''s > definitely possible to do. > > - EricThank you for the fast response. It works for me too now! -- Guenter This message posted from opensolaris.org
Michael Tibbetts
2005-Dec-01 19:56 UTC
[zfs-discuss] zfs pool based on nfs files. possible?
Adding nfs-discuss to the ''cc list. Eric Schrock wrote:>On Thu, Dec 01, 2005 at 04:41:23AM -0800, Guenter Feldmann wrote: > > >>We''re testing a bit around with zfs. Yesterday we created two files (each was >>1GB) and made a mirror out of it: >> zpool create tpool mirror /test/vol1 /test/vol2 >>It worked fine, so we wanted to do the same with mounted files from an nfs2 >>Filesystem and got the following error: >> >> zpool create pool2 mirror /test/nfs/host1/bigfile /test/nfs/host2/bigfile >> internal error: unexpected error 27 at line 444 of ../common/libzfs_pool.c >> >>Today we reproduced the error with nfs4 (to make sure it''s not a >>nfs2-problem) and received: >> >> internal error: unexpected error 13 at line 444 of ../common/libzfs_pool.c >> >>Same line, different error-codes. To us it''s looking more like a bug than a general >>limit of zfs. Will it be possible to work with zfs in the way we tried it (so what we found >>is just a bug) or haven''t you planned scenarios like this? >> >> > >Yes, these are definitely bugs in the sense that ZFS shouldn''t die with >''internal error'' messages. Please file bugs via opensolaris.org. But >the underlying causes look NFS-related, and no changes to ZFS can make >them work. > >In the first case, NFS is returning EFBIG for some operation. I don''t >know why; maybe kustarz can chime in. > >In the second case, you''re getting EACCES, presumably because root >doesn''t have access to these files over NFS. We need to pretty-print >this error code, but there''s nothing we can do about this case. > >I just created a pool over NFS and everything worked fine. I''m not sure >what kind of performance you''ll get in this configuration, but it''s >definitely possible to do. > >- Eric > >-- >Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock >_______________________________________________ >zfs-discuss mailing list >zfs-discuss at opensolaris.org >http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > >
Eric Schrock wrote:>On Thu, Dec 01, 2005 at 04:41:23AM -0800, Guenter Feldmann wrote: > > >>We''re testing a bit around with zfs. Yesterday we created two files (each was >>1GB) and made a mirror out of it: >> zpool create tpool mirror /test/vol1 /test/vol2 >>It worked fine, so we wanted to do the same with mounted files from an nfs2 >>Filesystem and got the following error: >> >> zpool create pool2 mirror /test/nfs/host1/bigfile /test/nfs/host2/bigfile >> internal error: unexpected error 27 at line 444 of ../common/libzfs_pool.c >> >>Hmm, i can''t seem to reproduce this particular error. on the server: fsh-weakfish# mkfile 1g /export/2g.txt fsh-weakfish# mkfile 1g /export/1g.txt on the client: fsh-suzuki# mount -o vers=2 fsh-weakfish:/export /mnt fsh-suzuki# ls -hl /mnt total 4196386 -rw------T 1 root root 1.0G Dec 1 14:33 1g.txt -rw------T 1 root root 1.0G Dec 1 14:32 2g.txt fsh-suzuki# zpool create pool2 mirror /mnt/1g.txt /mnt/2g.txt internal error: unexpected error 13 at line 444 of ../common/libzfs_pool.c fsh-suzuki# That error makes sense as Schrock explained (and you figured out already :) ). Now back on the server: fsh-weakfish# chmod 666 /export/2g.txt fsh-weakfish# chmod 666 /export/1g.txt And finally on the client: fsh-suzuki# ls -hl /mnt total 4196386 -rw-rw-rw- 1 root root 1.0G Dec 1 14:33 1g.txt -rw-rw-rw- 1 root root 1.0G Dec 1 14:32 2g.txt drwxr-xr-x 2 root root 512 Nov 9 13:06 home fsh-suzuki# zpool create pool2 mirror /mnt/1g.txt /mnt/2g.txt fsh-suzuki# zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT nfszfs - - - - FAULTED - pool2 1016M 164K 1016M 0% ONLINE - tar 68.0G 27.1M 68.0G 0% ONLINE - fsh-suzuki# echo "nfs2 i dislike you" > /pool2/nfs.txt fsh-suzuki# ls /pool2 nfs.txt fsh-suzuki# Perhaps the EFBIG is coming from a NFSv2 protocol limitation? I strongly discourage the use of NFSv2 in any event (v4 would be ideal). If you can reproduce i''d like to see it... glad to heard you got it working, eric>>Today we reproduced the error with nfs4 (to make sure it''s not a >>nfs2-problem) and received: >> >> internal error: unexpected error 13 at line 444 of ../common/libzfs_pool.c >> >>Same line, different error-codes. To us it''s looking more like a bug than a general >>limit of zfs. Will it be possible to work with zfs in the way we tried it (so what we found >>is just a bug) or haven''t you planned scenarios like this? >> >> > >Yes, these are definitely bugs in the sense that ZFS shouldn''t die with >''internal error'' messages. Please file bugs via opensolaris.org. But >the underlying causes look NFS-related, and no changes to ZFS can make >them work. > >In the first case, NFS is returning EFBIG for some operation. I don''t >know why; maybe kustarz can chime in. > >In the second case, you''re getting EACCES, presumably because root >doesn''t have access to these files over NFS. We need to pretty-print >this error code, but there''s nothing we can do about this case. > >I just created a pool over NFS and everything worked fine. I''m not sure >what kind of performance you''ll get in this configuration, but it''s >definitely possible to do. > >- Eric > >-- >Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock >_______________________________________________ >zfs-discuss mailing list >zfs-discuss at opensolaris.org >http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > >