[OpenIndiana-discuss] ZFS Error

[Gaetano Valboa]

I have been using openidiana since version 147, and earlier since
SunOS4, I have seen the same unsolved problem on illumos (BIOS drive C:
is disk0 BIOS drive D: is disk1 BIOS drive E: is disk2 BIOS drive F: is
disk3 BIOS drive G: is disk4 BIOS drive H: is disk5 BIOS drive I: is
disk6 ZFS: i / o error - all block copies unavailable ZFS: can't read
MOS of pool rpool). The usb disk works in fact I installed Ubuntu ZFS
20.10, kali with openzfs 2.0 and they work fine, but as you know it's
not SUN my first love. The thing that strikes me is that happens and
after update from 20.04 to 20.11. I'm waiting for your help !!! Thank
you all Gaetano Valboa from Sorrento - Naples - Italy www.valboa.net
e-mail gaetano at valboa.net

Il 23/01/21 06:52, Joshua M. Clulow ha scritto:
> Hi Gaetano,
>
> I'm sorry to hear about your drive troubles.  Data loss is always very
> unfortunate.  I've put some questions that you could answer for us
> towards the end of the e-mail, which might help us investigate what
> happened to your drive.
>
> On Fri, 22 Jan 2021 at 21:36, Hung Nguyen Gia via openindiana-discuss
> <openindiana-discuss at openindiana.org> wrote:
>> It's from experience. If a pool faulty on FreeBSD, I will try to import it on Linux or OI.
>> Of course, I will try to import it from FreeBSD first.
>> But most of the time it doesn't work.
>> The key is to import on other OSes that support ZFS.
>> The chance that it will be able to import the pool is higher.
> This is not good advice.  It sounds like there is corruption in the
> pool.  Making random changes to that software you're using (e.g.,
> different versions of the ZFS, or even different operating systems)
> doesn't increase the chance that you'll be able to import the pool; it
> merely increases the risk that you will make things worse.
>
> With corrupt file systems, you're generally in what is often described
> as an "incident pit":
>
>     https://en.wikipedia.org/wiki/Incident_pit
>
> Each time you make a move, you can either climb out (by fixing
> something) or fall further in (by making a bad choice).  Doing random
> things to the disk is very likely to drive you further into the pit;
> e.g., even importing a pool is a process that tries to write to the
> (possibly fragile or corrupt) media, and may make things worse.
>
> If you genuinely care about the data on the device, I would first make
> an image of the whole device and store it as a backup, using a
> read-only tool like "dd".  Then you can continue to operate on the
> errant volume with much lower risk.
>
> If you don't care about the data you've stored on the pool, and are
> asking why it has become corrupt after so little activity, we'll
> likely need some more information.  Some USB storage devices are
> notoriously unreliable, especially with respect to I/O operations that
> are critical to zpool integrity like cache flushes.
>
> ~ ~ ~ QUESTIONS: ~ ~ ~
>
> Some questions that might provide useful background information, either way:
>
>   - Is it a sealed all-in-one USB SSD unit, or an SSD device sitting
> in a USB enclosure?
>
>   - What model enclosure and/or SSD device?
>
>   - How old is the device, and have you used it in other systems before?
>
>   - Before the data loss event, did the system panic, or was the power
> to the system interrupted, or did the USB cable become disconnected at
> any point?
>
>
> Cheers.
>