On Mon, Jul 21, 2008 at 06:18:10PM -0300, Nenhum_de_Nos wrote:
The ZFS code in 7.0 is the same as in HEAD, so no worries.
I'm trying zfs myself in a small enviroment at home, but for that I do
follow 7-STABLE. there's no need to do that, as based in the above
statement ?
There might be
On Tue, July 22, 2008 06:07, Pawel Jakub Dawidek wrote:
On Mon, Jul 21, 2008 at 06:18:10PM -0300, Nenhum_de_Nos wrote:
The ZFS code in 7.0 is the same as in HEAD, so no worries.
I'm trying zfs myself in a small enviroment at home, but for that I do
follow 7-STABLE. there's no need to do
On Mon, Jul 21, 2008 at 12:29:54AM +0200, Daniel Eriksson wrote:
Pawel Jakub Dawidek wrote:
Can you try this patch?
http://people.freebsd.org/~pjd/patches/space_map.c.patch
Now it panics (solaris assert) at line 431 in dmu.c. I'll try to get a
backtrace in a day or two if it
On Mon, Jul 21, 2008 at 11:02:36AM +0200, Pawel Jakub Dawidek wrote:
On Mon, Jul 21, 2008 at 12:29:54AM +0200, Daniel Eriksson wrote:
Pawel Jakub Dawidek wrote:
Can you try this patch?
http://people.freebsd.org/~pjd/patches/space_map.c.patch
Now it panics (solaris assert) at
Pawel Jakub Dawidek wrote:
I'm afraid your pool's metadata is
somehow corrupted that ZFS can't handle that.
Yes, that's my conclusion also. It looks like the intent log is messed
up enough to trigger an assert while ZFS tries to parse/replay it.
I saw warnings in your
first e-mail about ZFS
On Mon, Jul 21, 2008 at 03:49:24PM +0200, Daniel Eriksson wrote:
Pawel Jakub Dawidek wrote:
I'm afraid your pool's metadata is
somehow corrupted that ZFS can't handle that.
Yes, that's my conclusion also. It looks like the intent log is messed
up enough to trigger an assert while ZFS
On Mon, Jul 21, 2008 at 03:51:56PM +0200, Pawel Jakub Dawidek wrote:
On Mon, Jul 21, 2008 at 03:49:24PM +0200, Daniel Eriksson wrote:
Pawel Jakub Dawidek wrote:
I'm afraid your pool's metadata is
somehow corrupted that ZFS can't handle that.
Yes, that's my conclusion also. It
The ZFS code in 7.0 is the same as in HEAD, so no worries.
I'm trying zfs myself in a small enviroment at home, but for that I do
follow 7-STABLE. there's no need to do that, as based in the above
statement ?
thanks,
matheus
--
We will call you cygnus,
The God of balance you shall be
Pawel Jakub Dawidek wrote:
Can you try this patch?
http://people.freebsd.org/~pjd/patches/space_map.c.patch
Now it panics (solaris assert) at line 431 in dmu.c. I'll try to get a
backtrace in a day or two if it would help.
Any other suggestions Pawel?
___
Daniel Eriksson
I've tried neither of these in your particular case, but they might be
worth a try:
Just a suggestion, but try specify vfs.zfs.zil_disable=1 or as a kernel
variable in the boot cli.
You may want to try export and import the pool and see how it likes it
then.
--
Alex
On Sat, 2008-07-19 at 10:51
Alex Trull wrote:
I've tried neither of these in your particular case, but they might be
worth a try:
Just a suggestion, but try specify vfs.zfs.zil_disable=1 or
as a kernel
variable in the boot cli.
You may want to try export and import the pool and see how it likes it
then.
I
Alex Trull wrote:
Just a suggestion, but try specify vfs.zfs.zil_disable=1 or
as a kernel variable in the boot cli.
I just tried this and unfortunately it didn't work. I got the exact same
kernel panic.
I've been looking through the code to try to find a way to fool ZFS into
thinking the
On Sat, 19 Jul 2008, Daniel Eriksson wrote:
DE Just a suggestion, but try specify vfs.zfs.zil_disable=1 or
DE as a kernel variable in the boot cli.
DE
DE I just tried this and unfortunately it didn't work. I got the exact same
DE kernel panic.
DE
DE I've been looking through the code to try
On Sat, Jul 19, 2008 at 10:51:21AM +0200, Daniel Eriksson wrote:
I have a large ZFS pool that seems to be partially corrupt, causing a
panic on ZFS startup. This is on a RELENG_7_0 machine.
This is what happens when I try to start ZFS (written down by hand):
ZFS: WARNING: can't process
14 matches
Mail list logo
