Date: Sat, 7 Feb 2009 00:23:27 +0100 From: Peter Schuller <peter.schuller@infidyne.com> To: Michael Gusek <michael.gusek@web.de> Cc: freebsd-current@freebsd.org Subject: Re: zfs: allocating allocated segment Message-ID: <20090206232327.GA19383@hyperion.scode.org> In-Reply-To: <200902051224.34442.michael.gusek@web.de> References: <200902051224.34442.michael.gusek@web.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--sm4nu43k4a2Rpi4c
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
> I'm running a File server with zfs, 64 Bit, 4 GB Ram and RELENG_7. Two da=
ys=20
> ago i uploaded a file via ftp to the server and the server is crashing. A=
fter=20
> reboot FreeBSD can't import the zfs-pool. There is a kernel-message:
>=20
> panic: Solaris(panic): zfs: allocating allocated=20
> segment(offset=3D123456... size=3D74)
>=20
> cpuid =3D 0
> Uptime: 14m22s
> panic: bufwrite: buffer is not busy???
>=20
> Now i try to import the zfs-pool with a recent 8.0-current but with the s=
ame=20
> result. It's very important to me to access the pool, so did you have som=
e=20
> idea's ?
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 recover fro=
m =
=
* otherwise-fatal errors, typically 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:+allocating+al=
located+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
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey@scode.org
E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org
--sm4nu43k4a2Rpi4c
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (FreeBSD)
iEYEARECAAYFAkmMxm8ACgkQDNor2+l1i319PwCg4CpxmcLUFQEH6O4AqAaNwhvc
wOAAoIzSxY8CdyNTdQ7VY9rBzcV9xdUQ
=+zfN
-----END PGP SIGNATURE-----
--sm4nu43k4a2Rpi4c--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090206232327.GA19383>