You might want to check out this thread:
http://opensolaris.org/jive/thread.jspa?messageID=435420
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discu
Does anyone know the correct syntax to use the zdb command on a
/dev/dsk/c6t0d0s2
I'm trying to determine the active uberblock on an attached USB drive.
> To identify the active uberblock I used zdb.
>
> r...@kestrel:/opt$ zdb -U -uuuv zones
> Uberblock
> magic = 00bab10c
> v
On Tue, Dec 16, 2008 at 12:07:52PM +, Ross Smith wrote:
> It sounds to me like there are several potentially valid filesystem
> uberblocks available, am I understanding this right?
>
> 1. There are four copies of the current uberblock. Any one of these
> should be enough to load your pool wit
Well done, Nathan, thank you taking on the additional effort to write it all up.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
It sounds to me like there are several potentially valid filesystem
uberblocks available, am I understanding this right?
1. There are four copies of the current uberblock. Any one of these
should be enough to load your pool with no data loss.
2. There are also a few (would love to know how many)
On Tue, Dec 16, 2008 at 1:43 PM, wrote:
>
>
> >When current uber-block A is detected to point to a corrupted on-disk
> data,
> >how would "zpool import" (or any other tool for that matter) quickly and
> >safely know that, once it found an older uber-block "B" that it points to
> a
> >set of block
>When current uber-block A is detected to point to a corrupted on-disk data,
>how would "zpool import" (or any other tool for that matter) quickly and
>safely know that, once it found an older uber-block "B" that it points to a
>set of blocks which does not include any blocks that has since been
On Tue, Dec 16, 2008 at 11:39 AM, Ross wrote:
> I know Eric mentioned the possibility of zpool import doing more of this
> kind of thing, and he said that it's current inability to do this will be
> fixed, but I don't know if it's an official project, RFE or bug. Can
> anybody shed some light on
I know Eric mentioned the possibility of zpool import doing more of this kind
of thing, and he said that it's current inability to do this will be fixed, but
I don't know if it's an official project, RFE or bug. Can anybody shed some
light on this?
See Jeff's post on Oct 10, and Eric's follow
On Mon, 15 Dec 2008 14:23:37 PST, Nathan Hand wrote:
[snip]
> Initial inspection of the filesystems are promising.
> I can read from files, there are no panics,
> everything seems to be intact.
Good work, congratulations, and thanks for the clear
description of the process. I hope I never need
I've had some success.
I started with the ZFS on-disk format PDF.
http://opensolaris.org/os/community/zfs/docs/ondiskformat0822.pdf
The uberblocks all have magic value 0x00bab10c. Used od -x to find that value
in the vdev.
r...@opensolaris:~# od -A x -x /mnt/zpool.zones | grep "b10c 00ba"
0200
I don't know if this is relevant or merely a coincidence but the zdb command
fails an assertion in the same txg_wait_synced function.
r...@opensolaris:~# zdb -p /mnt -e zones
Assertion failed: tx->tx_threads == 2, file ../../../uts/common/fs/zfs/txg.c,
line 423, function txg_wait_synced
Abort (
I have a ZFS pool that has been corrupted. The pool contains a single device
which was actually a file on UFS. The machine was accidentally halted and now
the pool is corrupt. There are (of course) no backups and I've been asked to
recover the pool. The system panics when trying to do anything w
13 matches
Mail list logo
