Ian Collins wrote:
...
> I don't know if anything else breaks when you do this, but if you are
> building software in a zone on a lofs filesystem, dmake hangs. Regular
> make works fine.
>
> The output from truss is:
>
> stat64("/export/home", 0x08045B60) = 0
> llseek(8, 0, SEEK_CUR) = 0
> llseek(8, 0, SEEK_SET) = 0
> ioctl(8, (('m'<<8)|7), 0x08045714) = 0
> ioctl(8, (('m'<<8)|7), 0x08045714) = 0
> ioctl(8, (('m'<<8)|7), 0x08045714) = 0
>
> repeated over and over.
Yup, I know. It's a complete p.i.t.a and I logged
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6553206
6553206 bringover from lofs to zfs fails, from lofs to ufs succeeds
to track it. My latest entries in the comments field are:
====================================================================
I haven't had a chance to update my system from snv_62 to 69 or later,
but I have just found out the *very* interesting (to me!) piece of
information that this bug does not occur when I run the bringover
in the global zone to a zfs filesystem - the problem only happens
in a non-global zone.
This is the pstack from a bringover in the non-global zone, to the
zfs-backed filesystem:
# pstack 24339
24339: bringover -p /ws/onnv-gate -w /scratch/src/build/rfes/mfi usr
fee2f807 _xstat (814bd21, 8045a60) + 7
080b13e7 __1cTavo_path_to_netpath6Fpc0_0_ (81529a0, 8045f0c) + e7
08083f59 __1cNAvo_workspaceIset_name6Mpc1_pnHAvo_err__ (8151d88, 804796a,
0) + 219
08083a12 __1cNAvo_workspace2t5B6MpcppnHAvo_err__v_ (8151d88, 804796a,
8047348) + 22
08088e59 __1cYavo_determine_default_ws6FpcppnNAvo_workspace__pnHAvo_err__
(804796a, 814ec44) + d9
080773fb __1cNAvo_bringoverKparse_args6M_pnHAvo_err__ (814ec30) + 27a
0807ce72 __1cPAvo_transactionLtransaction6M_pnHAvo_err__ (814ec30) + 22
08076de9 __1cNAvo_bringoverHcommand6M_v_ (814ec30) + 39
08076c58 main (6, 8047824, 8047840) + c8
08076afa ???????? (6, 804794c, 8047956, 8047959, 8047967, 804796a)
with the xstat call hanging.
*** (#2 of 3): 2007-09-07 17:00:45 EST [EMAIL PROTECTED]
This problem still occurs in snv_77.
To recreate:
* create a non-global zone. zoneroot can be on zfs or ufs
* add a filesystem which is zfs in the global zone, but which is
presented using lofs in the non-global zone
* boot the zone
* connect to the zone, via ssh or telnet
* from inside the zone bringover from the parent to the workspace
* twiddle thumbs
I also tried to narrow down the problem by running the following test *in
the global zone*:
* create a test directory on a zfs in the glbal zone
* cd to that directory
* bringover from the parent workspace (which either on ufs or zfs)
* watch the files come tumbling across to the test directory.
This means that the problem is not immediately with zfs, but rather with the
way that
zones are handling lofs presentation of zfs.
I also tried one further test - bringing over from the underlying
directory that the automounter presents as a /ws workspace. This
also failed to produce any output, with the bringover utility stuck
looping in the same functions as mentioned earlier in this CR's history.
====================================================================
James C. McPherson
--
Senior Kernel Software Engineer, Solaris
Sun Microsystems
http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
