Beyond the reporting problem of the disk in OpenBSD I'm going ahead with my 
analysis.

I'm performing an H3 test and H5 test on the CRC disk (backup #2) by a copy 
machine.

H3 test result is successful. I'm waiting for H5 test result and I am enough 
curious.

It shouldnt be a problem of disk capacity as attaching the same disk around 
three weeks
ago I didnt get the CRC advise.. further than not receiving any destination 
error by the copy
machine.

A CRC error caused by a bit-to-bit copy problem is strange enough.. and the 
source should be fine
as the 3rd backup is intact too.

For honesty I need to say that I hear clearly my first disk time-to-time having 
a mechanical glitch that
reoccurs from an age, like a typo of the typical regenerated drives...
I don't want that this *typo* manifested itself during the last second backup 
causing the CRC..

Let's see what are the H5 results..


-- Daniele Bonini

Mar 24, 2023 17:47:36 Daniele Bonini <my2...@aol.com>:

> 
> I checked backup #3 disk and faulty partition is perfectly intact.
> 
> So I came back to the faulty backup #2 disk and reattached it obtaining
> a slight different console output:
> 
> https://5md.at/l/obcons1
> 
> in this sense: I dont only receive the CRC error (on sd1, that it has
> same UID) but this time (after the fss_chk) I see the sd3 device just
> attached correctly too.
> 
> As said above, as the console CRC problem popup just after I inserted
> backup #2 disk I expect there is problem on that disk and there is a
> problem in OpenBSD caused by the same UID of the two disks. This
> statement comes confirmed from the fact that when I inserted backup #3
> disk all apparently was fine.
> 
> 
> -- Daniele Bonini
> 

Reply via email to