Am 12.12.13 17:14, schrieb Jan Owoc:
On Thu, Dec 12, 2013 at 8:50 AM, CJ Keist <cj.ke...@colostate.edu> wrote:
Thanks. Stephan,
What is the process or time frame of a bug fix in ZFS from Oracle making
it's way down to Illuminous and on to OI?
From what I understand, there isn't one. The two are developed
independently. However, features that are present in Oracle's ZFS may
have a higher priority of being independently re-implemented in OI,
but not necessarily in the same way.
That's right. Although the issue has been present in OSol and thus may
have made it over to Ilumos and it's ZUFS heritage, Oracle resolved this
bug later on and thus this fix won't make it into Ilumos or any of it's
decendants. It also may or may not have been addressed as a sidekick
through the many fixes the folks around here have issued to ZFS.
Am 11.12.13 21:28, schrieb Jim Klimov:
To make things even worse, this error is inside the data structure of
the ZFS fs, so zfs send/revc, doesn't help here and the data would have
to be copied "manually" - nasty indeed.
Is there anything stopping one from creating a new zfs on the same
pool, copying over the data "manually", and then destroying the
corrupt zfs? Or is the affected zfs generally larger than the free
space on the pool?
Well, no - there isn't. In the end it's the fs itself that corrupts and
not the zpool. This issue doesn't have any side effect on the zpool and
we have since created hundreds of new fs on that particular zpool.
Despite of the fact that the zfs automount will panic the system, there
is no other issue present with this fs. In the end it's not the zpool
that crashes, but the auto-mounting…
Cheers,
budy
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
