On 24/05/10 16:52 -0400, Frank Middleton wrote:
> Many many moons ago, I submitted a CR into bugs about a
> highly reproducible panic that occurs if you try to re-share
> a lofi mounted image. That CR has AFAIK long since
> disappeared - I even forget what it was called.
> This server is used for doing network installs. Let's say
> you have a 64 bit iso lofi-mounted and shared. You do the
> install, and then wish to switch to a 32 bit iso. You unshare,
> umount, delete the loopback, and then lofiadm the new iso,
> mount it and then share it. Panic, every time.
> Is this such a rare use-case that no one is interested? I have
> the backtrace and cores if anyone wants them, although
> such were submitted with the original CR. This is pretty
> frustrating since you start to run out of ideas for mountpoint
> names after a while unless you forget and get the panic.
> FWIW (even on a freshly booted system after a panic)
> # lofiadm zyzzy.iso /dev/lofi/1
> # mount -F hsfs /dev/lofi/1 /mnt
> mount: /dev/lofi/1 is already mounted or /mnt is busy
> # mount -O -F hsfs /dev/lofi/1 /mnt
> # share /mnt
> If you unshare /mnt and then do this again, it will panic.
> This has been a bug since before Open Solaris came out.
> It doesn't happen if the iso is originally on UFS, but
> UFS really isn't an option any more. FWIW the dataset
> containing the isos has the sharenfs attribute set,
> although it doesn;t have to be actually mounted by
> any remote NFS for this panic to occur.
> Suggestions for a workaround most welcome!
the bug (6798273) has been closed as incomplete with following
"I cannot reproduce any issue with the given testcase on b137."
So you should test this with b137 or newer build. There have
been some extensive changes going to treeclimb_* functions,
so the bug is probably fixed or will be in near future.
Let us know if you can still reproduce the panic on
zfs-discuss mailing list