Luke Scharf wrote:
This is also OT -- but what is the boot-archive, really?
Is it analogous to the initrd on Linux?
precisely.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Frank Cusack wrote:
On March 1, 2007 12:19:22 AM -0800 Jeff Bonwick <[EMAIL PROTECTED]>
wrote:
import it. Assuming this works, you can fix the stupid boot archive
thank you. i hate the boot archive. i have just spent MANY unnecessary
hours on some machines thanks to the stupid boot archive.
On March 1, 2007 12:19:22 AM -0800 Jeff Bonwick <[EMAIL PROTECTED]>
wrote:
import it. Assuming this works, you can fix the stupid boot archive
thank you. i hate the boot archive. i have just spent MANY unnecessary
hours on some machines thanks to the stupid boot archive.
(sorry, OT)
-frank
Hi Jeff,
> One possibility: I've seen this happen when a system doesn't shut down
> cleanly after the last change to the pool configuration. In this case,
> what can happen is that the boot archive (an annoying implementation
> detail of the new boot architecture) can be out of date relative to
>
> However, I logged in this morning to discover that the ZFS volume could
> not be read. In addition, it appears to have marked all drives, mirrors
> & the volume itself as 'corrupted'.
One possibility: I've seen this happen when a system doesn't shut down
cleanly after the last change to the pool
Further to this, I've considered doing the following:
1) Doing a zpool destroy on the volume
2) Doing a zpool import -D on the volume
It would appear to me that primarily what has occurred is one or all of
the metadata stores ZFS has created have become corrupt? Will a zpool
import -D ignore meta
Heya,
> Hmmm. This would indicate that vdev_dtl_load() is failing, which
> suggests that something vital got corrupted to the point where
> dmu_bonus_hold() or space_map_load() is failing. I don't know exactly
> how this is supposed to work, or how exactly to debug from
> here, so I'll let one o
On Thu, Mar 01, 2007 at 10:50:28AM +1000, Stuart Low wrote:
> Heya,
>
> > Sorry. Try 'echo vdev_load::dis | mdb -k'. This will give the
> > disassembly for vdev_load() in your current kernel (which will help us
> > pinpoint what vdev_load+0x69 is really doing).
>
> Ahh, thanks for that.
>
Hmm
Heya,
> Sorry. Try 'echo vdev_load::dis | mdb -k'. This will give the
> disassembly for vdev_load() in your current kernel (which will help us
> pinpoint what vdev_load+0x69 is really doing).
Ahh, thanks for that.
Attached.
Stuart
---
[EMAIL PROTECTED] ~]$ echo vdev_load::dis | mdb -k
vdev_
On Thu, Mar 01, 2007 at 10:46:02AM +1000, Stuart Low wrote:
> Heya,
>
> > The label looks sane. Can you try running:
>
> Not sure if I should be reassured by that but I'll hold my hopes
> high. :)
>
> > # dtrace -n vdev_set_state:entry'[EMAIL PROTECTED], args[3], stack()] =
> > count()}'
> > W
Heya,
> The label looks sane. Can you try running:
Not sure if I should be reassured by that but I'll hold my hopes
high. :)
> # dtrace -n vdev_set_state:entry'[EMAIL PROTECTED], args[3], stack()] =
> count()}'
> While executing 'zpool import' and send the output? Can you also send
> '::dis'
The label looks sane. Can you try running:
# dtrace -n vdev_set_state:entry'[EMAIL PROTECTED], args[3], stack()] =
count()}'
While executing 'zpool import' and send the output? Can you also send
'::dis' output (from 'mdb -k') of the function immediately above
vdev_set_state() in the above stac
Heya,
Firstly thanks for your help.
> That's quite strange.
Your telling me! :) I like ZFS I really do but this has dented my love
of it. :-/
> What version of ZFS are you running?
[EMAIL PROTECTED] ~]$ pkginfo -l SUNWzfsu
PKGINST: SUNWzfsu
NAME: ZFS (Usr)
CATEGORY: system
That's quite strange. What version of ZFS are you running? What does
'zdb -l /dev/dsk/c5t6006016031E0180032F8E9868E30DB11d0s0' show?
- eric
On Thu, Mar 01, 2007 at 09:31:05AM +1000, Stuart Low wrote:
> Hi there,
>
> We have been using ZFS for our backup storage since August last year.
> Overal
14 matches
Mail list logo
