On Mon, Oct 19, 2009 at 09:02:20PM -0500, Albert Chin wrote:
> On Mon, Oct 19, 2009 at 03:31:46PM -0700, Matthew Ahrens wrote:
> > Thanks for reporting this. I have fixed this bug (6822816) in build
> > 127.
>
> Thanks. I just installed OpenSolaris Preview based on 125 and will
> attempt to app
On Mon, Oct 19, 2009 at 03:31:46PM -0700, Matthew Ahrens wrote:
> Thanks for reporting this. I have fixed this bug (6822816) in build
> 127.
Thanks. I just installed OpenSolaris Preview based on 125 and will
attempt to apply the patch you made to this release and import the pool.
> --matt
>
>
Thanks for reporting this. I have fixed this bug (6822816) in build
127. Here is the evaluation from the bug report:
The problem is that the clone's dsobj does not appear in the origin's
ds_next_clones_obj.
The bug can occur can occur under certain circumstances if there was a
"botched upg
On Sun, Sep 27, 2009 at 10:06:16AM -0700, Andrew wrote:
> This is what my /var/adm/messages looks like:
>
> Sep 27 12:46:29 solaria genunix: [ID 403854 kern.notice] assertion failed: ss
> == NULL, file: ../../common/fs/zfs/space_map.c, line: 109
> Sep 27 12:46:29 solaria unix: [ID 10 kern.not
This is what my /var/adm/messages looks like:
Sep 27 12:46:29 solaria genunix: [ID 403854 kern.notice] assertion failed: ss
== NULL, file: ../../common/fs/zfs/space_map.c, line: 109
Sep 27 12:46:29 solaria unix: [ID 10 kern.notice]
Sep 27 12:46:29 solaria genunix: [ID 655072 kern.notice]
On Sun, Sep 27, 2009 at 12:25:28AM -0700, Andrew wrote:
> I'm getting the same thing now.
>
> I tried moving my 5-disk raidZ and 2disk Mirror over to another
> machine, but that machine would keep panic'ing (not ZFS related
> panics). When I brought the array back over, I started getting this as
>
I'm getting the same thing now.
I tried moving my 5-disk raidZ and 2disk Mirror over to another machine, but
that machine would keep panic'ing (not ZFS related panics). When I brought the
array back over, I started getting this as well.. My Mirror array is unaffected.
snv111b (2009.06 release)
Richard Elling wrote:
Assertion failures indicate bugs. You might try another version of the OS.
In general, they are easy to search for in the bugs database. A quick
search reveals
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6822816
but that doesn't look like it will help you. I
Assertion failures indicate bugs. You might try another version of the
OS.
In general, they are easy to search for in the bugs database. A quick
search reveals
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6822816
but that doesn't look like it will help you. I suggest filing a new
On Fri, Sep 25, 2009 at 05:21:23AM +, Albert Chin wrote:
> [[ snip snip ]]
>
> We really need to import this pool. Is there a way around this? We do
> have snv_114 source on the system if we need to make changes to
> usr/src/uts/common/fs/zfs/dsl_dataset.c. It seems like the "zfs
> destroy" tr
Running snv_114 on an X4100M2 connected to a 6140. Made a clone of a
snapshot a few days ago:
# zfs snapshot a...@b
# zfs clone a...@b tank/a
# zfs clone a...@b tank/b
The system started panicing after I tried:
# zfs snapshot tank/b...@backup
So, I destroyed tank/b:
# zfs destroy tank/b
11 matches
Mail list logo
