fsck: CANNOT READ: BLK 4235468160

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

fsck: CANNOT READ: BLK 4235468160

Maximilian Pichler
Hi,

I'm running fsck on an external USB hard drive, using OpenBSD 6.2
inside VirtualBox on MacOS.

On each run it gives a handful of "CANNOT READ: BLK ..." messages, but
the block numbers reported are different (!) each time.

If the disk is damaged, shouldn't the problematic blocks be
consistent? Does this point to a communication problem with the disk
(e.g. faulty USB cable)? Or is this a hopelessly unstable situation
given the general screwiness of USB over VirtualBox/Mac OS...?

Also, does answering "y" to "CANNOT READ" modify the disk contents?

Thanks for any insights!

Max


xhci0 at pci0 dev 12 function 0 "Intel 7 Series xHCI" rev 0x00: apic 2 int 20
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev
3.00/1.00 addr 1
umass0 at uhub0 port 9 configuration 1 interface 0 "Seagate Expansion"
rev 3.00/0.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus4 at umass0: 2 targets, initiator 0
sd0 at scsibus4 targ 1 lun 0: <Seagate, Expansion, 9300> SCSI4 0/direct fixed
sd0: 3815447MB, 512 bytes/sector, 7814037167 sectors

$ doas fsck /dev/sd0a
** /dev/rsd0a
** Last Mounted on /home/max/mnt
** Phase 1 - Check Blocks and Sizes

CANNOT READ: BLK 4235468160
CONTINUE? [Fyn?] y

THE FOLLOWING DISK SECTORS COULD NOT BE READ:

CANNOT READ: BLK 4128081280
CONTINUE? [Fyn?] y

THE FOLLOWING DISK SECTORS COULD NOT BE READ:
CANNOT READ: BLK 4194986880
CONTINUE? [Fyn?] y
CONTINUE? [Fyn?] y

THE FOLLOWING DISK SECTORS COULD NOT BE READ:
** Phase 2 - Check Pathnames

CANNOT READ: BLK 4195146384
CONTINUE? [Fyn?] y
CONTINUE? [Fyn?] y

THE FOLLOWING DISK SECTORS COULD NOT BE READ:
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
614222 files, 408012667 used, 76524122 free (3658 frags, 9565058
blocks, 0.0% fragmentation)

MARK FILE SYSTEM CLEAN? [Fyn?] y


***** FILE SYSTEM WAS MODIFIED *****


$ doas fsck -f /dev/sd0a
** /dev/rsd0a
** File system is already clean
** Last Mounted on /home/max/mnt
** Phase 1 - Check Blocks and Sizes

CANNOT READ: BLK 4236615424
CONTINUE? [Fyn?] y

THE FOLLOWING DISK SECTORS COULD NOT BE READ:
** Phase 2 - Check Pathnames

CANNOT READ: BLK 3732315520
CONTINUE? [Fyn?] y

THE FOLLOWING DISK SECTORS COULD NOT BE READ:

CANNOT READ: BLK 4161885792
CONTINUE? [Fyn?] y

THE FOLLOWING DISK SECTORS COULD NOT BE READ:

CANNOT READ: BLK 4201995728
CONTINUE? [Fyn?] y

THE FOLLOWING DISK SECTORS COULD NOT BE READ:

CANNOT READ: BLK 4202008160
CONTINUE? [Fyn?] y

THE FOLLOWING DISK SECTORS COULD NOT BE READ:

CANNOT READ: BLK 4202013680
CONTINUE? [Fyn?] y

THE FOLLOWING DISK SECTORS COULD NOT BE READ:
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups

CANNOT READ: BLK 5011229824
CONTINUE? [Fyn?] y

THE FOLLOWING DISK SECTORS COULD NOT BE READ:
614222 files, 408012667 used, 76524122 free (3658 frags, 9565058
blocks, 0.0% fragmentation)

Reply | Threaded
Open this post in threaded view
|

Re: fsck: CANNOT READ: BLK 4235468160

STeve Andre'
When you enter the realm of hardware errors, anything can happen.  If
you are lucky you will see the same hard and soft errors every time you
cross a bad sector, but I have seen many cases wildly varying block
numbers on really sick disks.  And yes, bad cables and USB interfaces
can be a problem too.  Try wiggling the cable disk the disk stable and
see if you can produce errors.

Try doing a read with that USB hardware on another disk, too. That will
tell you something.  I'll bet that the disk is bad.  If it stops
producing errors, don't forgive it!  Get a new one.

--STeve Andre'

On 01/06/18 21:45, Maximilian Pichler wrote:

> Hi,
>
> I'm running fsck on an external USB hard drive, using OpenBSD 6.2
> inside VirtualBox on MacOS.
>
> On each run it gives a handful of "CANNOT READ: BLK ..." messages, but
> the block numbers reported are different (!) each time.
>
> If the disk is damaged, shouldn't the problematic blocks be
> consistent? Does this point to a communication problem with the disk
> (e.g. faulty USB cable)? Or is this a hopelessly unstable situation
> given the general screwiness of USB over VirtualBox/Mac OS...?
>
> Also, does answering "y" to "CANNOT READ" modify the disk contents?
>
> Thanks for any insights!
>
> Max
>
>
> xhci0 at pci0 dev 12 function 0 "Intel 7 Series xHCI" rev 0x00: apic 2 int 20
> usb0 at xhci0: USB revision 3.0
> uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev
> 3.00/1.00 addr 1
> umass0 at uhub0 port 9 configuration 1 interface 0 "Seagate Expansion"
> rev 3.00/0.00 addr 2
> umass0: using SCSI over Bulk-Only
> scsibus4 at umass0: 2 targets, initiator 0
> sd0 at scsibus4 targ 1 lun 0: <Seagate, Expansion, 9300> SCSI4 0/direct fixed
> sd0: 3815447MB, 512 bytes/sector, 7814037167 sectors
>
> $ doas fsck /dev/sd0a
> ** /dev/rsd0a
> ** Last Mounted on /home/max/mnt
> ** Phase 1 - Check Blocks and Sizes
>
> CANNOT READ: BLK 4235468160
> CONTINUE? [Fyn?] y
>
> THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>
> CANNOT READ: BLK 4128081280
> CONTINUE? [Fyn?] y
>
> THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> CANNOT READ: BLK 4194986880
> CONTINUE? [Fyn?] y
> CONTINUE? [Fyn?] y
>
> THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> ** Phase 2 - Check Pathnames
>
> CANNOT READ: BLK 4195146384
> CONTINUE? [Fyn?] y
> CONTINUE? [Fyn?] y
>
> THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> ** Phase 5 - Check Cyl groups
> 614222 files, 408012667 used, 76524122 free (3658 frags, 9565058
> blocks, 0.0% fragmentation)
>
> MARK FILE SYSTEM CLEAN? [Fyn?] y
>
>
> ***** FILE SYSTEM WAS MODIFIED *****
>
>
> $ doas fsck -f /dev/sd0a
> ** /dev/rsd0a
> ** File system is already clean
> ** Last Mounted on /home/max/mnt
> ** Phase 1 - Check Blocks and Sizes
>
> CANNOT READ: BLK 4236615424
> CONTINUE? [Fyn?] y
>
> THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> ** Phase 2 - Check Pathnames
>
> CANNOT READ: BLK 3732315520
> CONTINUE? [Fyn?] y
>
> THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>
> CANNOT READ: BLK 4161885792
> CONTINUE? [Fyn?] y
>
> THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>
> CANNOT READ: BLK 4201995728
> CONTINUE? [Fyn?] y
>
> THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>
> CANNOT READ: BLK 4202008160
> CONTINUE? [Fyn?] y
>
> THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>
> CANNOT READ: BLK 4202013680
> CONTINUE? [Fyn?] y
>
> THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> ** Phase 5 - Check Cyl groups
>
> CANNOT READ: BLK 5011229824
> CONTINUE? [Fyn?] y
>
> THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> 614222 files, 408012667 used, 76524122 free (3658 frags, 9565058
> blocks, 0.0% fragmentation)
>
>

Reply | Threaded
Open this post in threaded view
|

Re: fsck: CANNOT READ: BLK 4235468160

Chris M-2
With disks, the blocks can change. There can be any number of reasons for
this, from the actual physical platters going bad to the read heads not
functioning properly, or the memory on the disk going bad. SSD is a
different story, in my experience when it begins to go the behavior becomes
really erratic and inconsistent. You could try replacing cables, but you
are probably looking at replacing the disk.


On Sat, Jan 6, 2018 at 9:12 PM STeve Andre' <[hidden email]> wrote:

> When you enter the realm of hardware errors, anything can happen.  If
> you are lucky you will see the same hard and soft errors every time you
> cross a bad sector, but I have seen many cases wildly varying block
> numbers on really sick disks.  And yes, bad cables and USB interfaces
> can be a problem too.  Try wiggling the cable disk the disk stable and
> see if you can produce errors.
>
> Try doing a read with that USB hardware on another disk, too. That will
> tell you something.  I'll bet that the disk is bad.  If it stops
> producing errors, don't forgive it!  Get a new one.
>
> --STeve Andre'
>
> On 01/06/18 21:45, Maximilian Pichler wrote:
> > Hi,
> >
> > I'm running fsck on an external USB hard drive, using OpenBSD 6.2
> > inside VirtualBox on MacOS.
> >
> > On each run it gives a handful of "CANNOT READ: BLK ..." messages, but
> > the block numbers reported are different (!) each time.
> >
> > If the disk is damaged, shouldn't the problematic blocks be
> > consistent? Does this point to a communication problem with the disk
> > (e.g. faulty USB cable)? Or is this a hopelessly unstable situation
> > given the general screwiness of USB over VirtualBox/Mac OS...?
> >
> > Also, does answering "y" to "CANNOT READ" modify the disk contents?
> >
> > Thanks for any insights!
> >
> > Max
> >
> >
> > xhci0 at pci0 dev 12 function 0 "Intel 7 Series xHCI" rev 0x00: apic 2
> int 20
> > usb0 at xhci0: USB revision 3.0
> > uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev
> > 3.00/1.00 addr 1
> > umass0 at uhub0 port 9 configuration 1 interface 0 "Seagate Expansion"
> > rev 3.00/0.00 addr 2
> > umass0: using SCSI over Bulk-Only
> > scsibus4 at umass0: 2 targets, initiator 0
> > sd0 at scsibus4 targ 1 lun 0: <Seagate, Expansion, 9300> SCSI4 0/direct
> fixed
> > sd0: 3815447MB, 512 bytes/sector, 7814037167 <(781)%20403-7167> sectors
> >
> > $ doas fsck /dev/sd0a
> > ** /dev/rsd0a
> > ** Last Mounted on /home/max/mnt
> > ** Phase 1 - Check Blocks and Sizes
> >
> > CANNOT READ: BLK 4235468160 <(423)%20546-8160>
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> >
> > CANNOT READ: BLK 4128081280 <(412)%20808-1280>
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> > CANNOT READ: BLK 4194986880 <(419)%20498-6880>
> > CONTINUE? [Fyn?] y
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> > ** Phase 2 - Check Pathnames
> >
> > CANNOT READ: BLK 4195146384 <(419)%20514-6384>
> > CONTINUE? [Fyn?] y
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> > ** Phase 3 - Check Connectivity
> > ** Phase 4 - Check Reference Counts
> > ** Phase 5 - Check Cyl groups
> > 614222 files, 408012667 used, 76524122 free (3658 frags, 9565058
> > blocks, 0.0% fragmentation)
> >
> > MARK FILE SYSTEM CLEAN? [Fyn?] y
> >
> >
> > ***** FILE SYSTEM WAS MODIFIED *****
> >
> >
> > $ doas fsck -f /dev/sd0a
> > ** /dev/rsd0a
> > ** File system is already clean
> > ** Last Mounted on /home/max/mnt
> > ** Phase 1 - Check Blocks and Sizes
> >
> > CANNOT READ: BLK 4236615424 <(423)%20661-5424>
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> > ** Phase 2 - Check Pathnames
> >
> > CANNOT READ: BLK 3732315520
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> >
> > CANNOT READ: BLK 4161885792
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> >
> > CANNOT READ: BLK 4201995728
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> >
> > CANNOT READ: BLK 4202008160
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> >
> > CANNOT READ: BLK 4202013680
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> > ** Phase 3 - Check Connectivity
> > ** Phase 4 - Check Reference Counts
> > ** Phase 5 - Check Cyl groups
> >
> > CANNOT READ: BLK 5011229824
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> > 614222 files, 408012667 used, 76524122 free (3658 frags, 9565058
> > blocks, 0.0% fragmentation)
> >
> >
>
>

--
There's no place like 127.0.0.1
Reply | Threaded
Open this post in threaded view
|

Re: fsck: CANNOT READ: BLK 4235468160

Chris M-2
I just saw you mentioned you are using the disk inside of virtualbox. Does
this same thing happen if you use the disk natively?


On Mon, Jan 8, 2018 at 8:52 AM Matt M <[hidden email]> wrote:

> With disks, the blocks can change. There can be any number of reasons for
> this, from the actual physical platters going bad to the read heads not
> functioning properly, or the memory on the disk going bad. SSD is a
> different story, in my experience when it begins to go the behavior becomes
> really erratic and inconsistent. You could try replacing cables, but you
> are probably looking at replacing the disk.
>
>
> On Sat, Jan 6, 2018 at 9:12 PM STeve Andre' <[hidden email]> wrote:
>
>> When you enter the realm of hardware errors, anything can happen.  If
>> you are lucky you will see the same hard and soft errors every time you
>> cross a bad sector, but I have seen many cases wildly varying block
>> numbers on really sick disks.  And yes, bad cables and USB interfaces
>> can be a problem too.  Try wiggling the cable disk the disk stable and
>> see if you can produce errors.
>>
>> Try doing a read with that USB hardware on another disk, too. That will
>> tell you something.  I'll bet that the disk is bad.  If it stops
>> producing errors, don't forgive it!  Get a new one.
>>
>> --STeve Andre'
>>
>> On 01/06/18 21:45, Maximilian Pichler wrote:
>> > Hi,
>> >
>> > I'm running fsck on an external USB hard drive, using OpenBSD 6.2
>> > inside VirtualBox on MacOS.
>> >
>> > On each run it gives a handful of "CANNOT READ: BLK ..." messages, but
>> > the block numbers reported are different (!) each time.
>> >
>> > If the disk is damaged, shouldn't the problematic blocks be
>> > consistent? Does this point to a communication problem with the disk
>> > (e.g. faulty USB cable)? Or is this a hopelessly unstable situation
>> > given the general screwiness of USB over VirtualBox/Mac OS...?
>> >
>> > Also, does answering "y" to "CANNOT READ" modify the disk contents?
>> >
>> > Thanks for any insights!
>> >
>> > Max
>> >
>> >
>> > xhci0 at pci0 dev 12 function 0 "Intel 7 Series xHCI" rev 0x00: apic 2
>> int 20
>> > usb0 at xhci0: USB revision 3.0
>> > uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev
>> > 3.00/1.00 addr 1
>> > umass0 at uhub0 port 9 configuration 1 interface 0 "Seagate Expansion"
>> > rev 3.00/0.00 addr 2
>> > umass0: using SCSI over Bulk-Only
>> > scsibus4 at umass0: 2 targets, initiator 0
>> > sd0 at scsibus4 targ 1 lun 0: <Seagate, Expansion, 9300> SCSI4 0/direct
>> fixed
>> > sd0: 3815447MB, 512 bytes/sector, 7814037167 <(781)%20403-7167> sectors
>> >
>> > $ doas fsck /dev/sd0a
>> > ** /dev/rsd0a
>> > ** Last Mounted on /home/max/mnt
>> > ** Phase 1 - Check Blocks and Sizes
>> >
>> > CANNOT READ: BLK 4235468160 <(423)%20546-8160>
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> >
>> > CANNOT READ: BLK 4128081280 <(412)%20808-1280>
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> > CANNOT READ: BLK 4194986880 <(419)%20498-6880>
>> > CONTINUE? [Fyn?] y
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> > ** Phase 2 - Check Pathnames
>> >
>> > CANNOT READ: BLK 4195146384 <(419)%20514-6384>
>> > CONTINUE? [Fyn?] y
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> > ** Phase 3 - Check Connectivity
>> > ** Phase 4 - Check Reference Counts
>> > ** Phase 5 - Check Cyl groups
>> > 614222 files, 408012667 used, 76524122 free (3658 frags, 9565058
>> > blocks, 0.0% fragmentation)
>> >
>> > MARK FILE SYSTEM CLEAN? [Fyn?] y
>> >
>> >
>> > ***** FILE SYSTEM WAS MODIFIED *****
>> >
>> >
>> > $ doas fsck -f /dev/sd0a
>> > ** /dev/rsd0a
>> > ** File system is already clean
>> > ** Last Mounted on /home/max/mnt
>> > ** Phase 1 - Check Blocks and Sizes
>> >
>> > CANNOT READ: BLK 4236615424 <(423)%20661-5424>
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> > ** Phase 2 - Check Pathnames
>> >
>> > CANNOT READ: BLK 3732315520
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> >
>> > CANNOT READ: BLK 4161885792
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> >
>> > CANNOT READ: BLK 4201995728
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> >
>> > CANNOT READ: BLK 4202008160
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> >
>> > CANNOT READ: BLK 4202013680
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> > ** Phase 3 - Check Connectivity
>> > ** Phase 4 - Check Reference Counts
>> > ** Phase 5 - Check Cyl groups
>> >
>> > CANNOT READ: BLK 5011229824
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> > 614222 files, 408012667 used, 76524122 free (3658 frags, 9565058
>> > blocks, 0.0% fragmentation)
>> >
>> >
>>
>>
>
> --
> There's no place like 127.0.0.1
>


--
There's no place like 127.0.0.1
Reply | Threaded
Open this post in threaded view
|

Re: fsck: CANNOT READ: BLK 4235468160

Boudewijn Dijkstra-3
In reply to this post by Maximilian Pichler
Op Sun, 07 Jan 2018 03:45:06 +0100 schreef Maximilian Pichler  
<[hidden email]>:
> If the disk is damaged, shouldn't the problematic blocks be
> consistent?

If you mean the actual platters, then probably yes, but there are other  
components that can damage. If for instance the bearings are worn, you can  
get a HDD that works fine at first and starts getting more and more read  
errors as it heats up.