d by dtrace - core developers of dtrace
> were quite interested in the kernel crash dump.
>
> http://mail.opensolaris.org/pipermail/zfs-discuss/2008-September/051109.html
> Panic during ON build. Pool was lost, no response from list.
>
> --
> Mike Gerdts
> http://mgerdt
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
--
Timh Bergström
System Administrator
Diino AB - www.diino.com
:wq
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
2008/10/10 Richard Elling <[EMAIL PROTECTED]>:
> Timh Bergström wrote:
>>
>> 2008/10/9 Bob Friesenhahn <[EMAIL PROTECTED]>:
>>
>>>
>>> On Thu, 9 Oct 2008, Miles Nordin wrote:
>>>
>>>>
>>>> catastrophically. If thi
repaired?
I know I should have backups but I dont, and if it's a lost cause it's
fine, the data itself is not important.
--
Timh Bergström
System Operations Manager
Diino AB - www.diino.com
:wq
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
e
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6587723
> which was fixed a long time ago. You might check that bug against your
> stack trace (which was not included in this post).
>
> You may be able to boot from a later OS release and import/export the pool
> to repair.
> -- ric
> Ian.
>
> ___
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
--
Timh Bergström
System Operations Manager
Diino AB - www.diino.com
:wq
Den 18 juni 2009 06.47 skrev Timh Bergström:
> The way I see it is that eventhough ZFS may be a wonderful filesystem,
> it is not the best solution for every possible (odd) setup. I.e
> USB-sticks has proven a bad idea with zfs mirrors, ergo - dont do
> it(tm).
>
> ZFS on iSCS
Den 18 juni 2009 09.42 skrev Bogdan M. Maryniuk:
>> ZFS on iSCSI *is* flaky
> OK, so what is the status of your bugreport about this? Was ignored or
> just rejected?..
No bug report because I don't think it's the file systems fault, and
why bother when disappearing vdevs (even though the pool is f