Date: Sat, 07 Feb 2009 11:53:24 +0100 From: Michael Gusek <michael.gusek@web.de> To: freebsd-current@freebsd.org Subject: Re: zfs: allocating allocated segment Message-ID: <498D6824.8060303@web.de> In-Reply-To: <20090206232327.GA19383@hyperion.scode.org> References: <200902051224.34442.michael.gusek@web.de> <20090206232327.GA19383@hyperion.scode.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Schuller schrieb:
>> I'm running a File server with zfs, 64 Bit, 4 GB Ram and RELENG_7. Two=
days=20
>> ago i uploaded a file via ftp to the server and the server is crashing=
=2E After=20
>> reboot FreeBSD can't import the zfs-pool. There is a kernel-message:
>>
>> panic: Solaris(panic): zfs: allocating allocated=20
>> segment(offset=3D123456... size=3D74)
>>
>> cpuid =3D 0
>> Uptime: 14m22s
>> panic: bufwrite: buffer is not busy???
>>
>> Now i try to import the zfs-pool with a recent 8.0-current but with th=
e same=20
>> result. It's very important to me to access the pool, so did you have =
some=20
>> idea's ?
>> =20
>
> The ZFS panic is from space_map.c in space_map_add(), happening via
> zfs_panic_recover(). It in turn is affected by zfs_recover:
>
> /* =
=
=
* zfs_recover can be set to nonzero to attempt to r=
ecover from =
=
* otherwise-fatal errors, typica=
lly caused by on-disk corruption. When =
=
* set, calls =
to zfs_panic_recover() will turn into warning messages. =
=
=
*/
>
> Setting the vfs.zfs.recover loader variable to 1 might possibly
> help. However I have never tried using that option and I'm not
> familiar with the code, so I have no idea how safe it is. In
> particular since you then seem to be getting a secondary panic (the
> "buffer is not busy" which is from ffs_vfsops.
>
> On another note:
>
> http://www.google.com/search?client=3Dopera&rls=3Den&q=3Dzfs:+allocatin=
g+allocated+segment&sourceid=3Dopera&ie=3Dutf-8&oe=3Dutf-8
>
> indicates you're not the only person who has seen similar
> errors. Unfortunately I cannot offer any insight other than to suggest
> digging through the google results.
>
> Was the original crash, prior to the mount problem, purely a software
> crash or was there, for example, a power outtage? I'm wondering
> whether there is any particular reason to believe there was some
> hardware/firmware fault causing corruption.
>
> =20
Thank you for your response Petter,
on Monday i will give vfs.zfs.recover a try. The original crash was=20
beeing a ftp upload. There was'nt a power outtage or another kernel=20
message, so i don't think it is an hardware issue.
Regards,
Michael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?498D6824.8060303>