newer zfs version
Rene Madsen
I had an old esos 4.0.3 with zfs-0.8.3.1 with a raidz2 zpool.
After an unfortunately power failure, one disk went unavailable and scst would not load
Zpool import showed that the pool should be importable (se command traces below)
And zdb commands indicated that all structures was ok except that where was a
Space map refcount mismatch.
Googling indicates that this a normal recoverable state fixable my scrubbing
However any attempt to zpool import bigpool failed.
Further googling indicates that a newer version of zfs could be able to fix this problem.
Therefor I undertook the task of upgrading to the newest esos 4.3.x.
But to my big surprise the latest esos is still using zfs-0.8.3.1. (newest is 2.2.7)
Is where any reason for that? I in the hope of 4 years of zfs development will have a more robust refcount recovery.
Any suggestions on how to proceed.
Any help is appreciated
Thanks in advance
René
-----------------------------
# zpool import
pool: bigpool
id: 6541512305805687005
state: DEGRADED
status: One or more devices contains corrupted data.
action: The pool can be imported despite missing or damaged devices. The
fault tolerance of the pool may be compromised if imported.
see: http://zfsonlinux.org/msg/ZFS-8000-4J
config:
bigpool DEGRADED
raidz2-0 DEGRADED
wwn-0x5000cca26670a9bc ONLINE
wwn-0x5000cca26670adb0 ONLINE
wwn-0x5000cca2666fb79c ONLINE
wwn-0x5000cca2665f5328 ONLINE
wwn-0x5000cca26670d85c ONLINE
wwn-0x5000cca266704304 ONLINE
wwn-0x5000cca2665a719c ONLINE
wwn-0x5000cca2667017d8 ONLINE
wwn-0x5000cca266626be0 ONLINE
wwn-0x5000cca2666f3960 UNAVAIL
wwn-0x5000cca26652c3c4 ONLINE
wwn-0x5000cca266702618 ONLINE
wwn-0x5000cca26670d1d0 ONLINE
logs
nvme0n1 ONLINE
# zfs version
zfs-0.8.3-1
zfs-kmod-0.8.3-1
# zpool import bigpool
cannot import 'bigpool': I/O error
Destroy and re-create the pool from
a backup source.
Marc Smith
>
> I had an old esos 4.0.3 with zfs-0.8.3.1 with a raidz2 zpool.
>
> After an unfortunately power failure, one disk went unavailable and scst would not load
>
> Zpool import showed that the pool should be importable (se command traces below)
>
> And zdb commands indicated that all structures was ok except that where was a
>
> Space map refcount mismatch.
>
> Googling indicates that this a normal recoverable state fixable my scrubbing
>
> However any attempt to zpool import bigpool failed.
>
> Further googling indicates that a newer version of zfs could be able to fix this problem.
>
> Therefor I undertook the task of upgrading to the newest esos 4.3.x.
>
> But to my big surprise the latest esos is still using zfs-0.8.3.1. (newest is 2.2.7)
>
> Is where any reason for that? I in the hope of 4 years of zfs development will have a more robust refcount recovery.
myself sometime back but found the direct I/O performance to be
dismal. Any idea if this is improved in newer versions?
I can look at updating this in the future, but I'm short on cycles
right now. If you're able to clone the ESOS source from GitHub and
develop a patch (sending via GH pull request is ideal) to use the
newest version, I'd happily pull this in!
--Marc
> You received this message because you are subscribed to the Google Groups "esos-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to esos-users+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/esos-users/37236e70-372c-4bae-8e2b-7676992d57e0n%40googlegroups.com.
Roland privat
dismal. Any idea if this is improved in newer versions?
To view this discussion visit https://groups.google.com/d/msgid/esos-users/CAH6h%2BhdcjGqtFZUR_f-d7H3tGryB-8ZCc9k2YjeYu99jKqKZOg%40mail.gmail.com.