On Mon, 04 Feb 2008 14:23:48 +0100, Miro <totoro32 at gmail.com> wrote:
>> 6614416 panic in spec_fsync() when creating a device file via NFS
>>
>> and is not yet fixed.
>>
>> workaround: On the NFS server, share the filesystems with the "-o nodevices"
>> option to the "share" command. That makes the operation fail before ever
>> reaching the VOP_FSYNC() call.
>
> I don't see this option in share:
>
> # zfs set
> sharenfs=ro=91.121.194.1,rw=91.121.194.1,root=91.121.194.1,nodevices
> tankmirror/vol1001
> cannot share 'tankmirror/vol1001': invalid share option: 'nodevices'
> property may be set but unable to reshare filesystem
>
> # share -o nodevices /tankmirror/vol1001
> share_nfs: invalid share option: 'nodevices'
Urghh....look, that's what happens if you rely on a workaround someone else has
put into the
bug without verufying it :(
actually it should have been - mount the underlaying file system at the server
with the 'nodevices' mount option, from mount(1M)
<snip>
devices | nodevices
Allow or disallow the opening of device-special
files. The default is devices.
If you use nosuid in conjunction with devices,
the behavior is equivalent to that of nosuid.
<snip end>
>
>> can you tell me the underlaying device/driver that is serving the NFS server
>> ?
>> is it SVM, ZFS ?
>
> It's ZFS for me, but under UFS I see the same bug. If you need any debug,
> tell me how I can help you.
makes sense it's the underlaying driver causing us to barf :(
I'd suggest the best for your particular case is to open a service case and it
will get
all the way thru the team responsible for fixing. Please keep the dump for that
purpose.
---
frankB
