[SOLVED] Can HP StorageWorks 215 tape cause FC26 KDE GUI to be stuck?

dc.901 · 11-18-2018, 05:57 PM

Can you run fsck again after unmounting filesystem with command:

Code:

e2fsck -f -c -v <your file system>

Man page is here: https://linux.die.net/man/8/e2fsck

And, what OS/kernel is the system running?

Code:

uname -a
cat /etc/*release*

Did you apply any updates on Oct 28th?

And, how many times did the system ran full backup since Oct 28th?
I am wondering if sdb is reporting errors every time full backup is done?
During full backup it will read thru all data, and if that sector is bad, you will see error.
Now, during normal operation (or incremental backups) if that data on bad sector is not accessed, you will not see those errors.

kaza · 11-20-2018, 12:12 PM

Hi dc.901,

my OS is:

Code:

uname -a
Linux localhost.localdomain 4.15.6-200.spi_gpio.fc26.x86_64 #1 SMP Sat Mar 3 02:13:51 IST 2018 x86_64 x86_64 x86_64 GNU/Linux


cat /etc/*release*
Fedora release 26 (Twenty Six)
NAME=Fedora
VERSION="26 (Twenty Six)"
ID=fedora
VERSION_ID=26
PRETTY_NAME="Fedora 26 (Twenty Six)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:26"
HOME_URL="https://fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=26
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=26
PRIVACY_POLICY_URL=https://fedoraproject.org/wiki/Legal:PrivacyPolicy
Fedora release 26 (Twenty Six)
Fedora release 26 (Twenty Six)
cpe:/o:fedoraproject:fedora:26

and the more important: when I run the "e2fsck -f -c -v /dev/VolGroup_graphics/lv_graphics"
this time it took almost 5 hours and the progress line ended being:

Checking bad blocks (read_only test): 100.00% done, 4:59:04 elapsed. (842208107/0/0 errors).

Again, just like with backups, the GUI stuck when I came after the "e2fsck" run
and I had to write down the progress line. It makes sense: when some SW reas the WHOLE disk
it encounters some problematic place which is causing the problem.

How could my disk work reasonably well with such an enormous number of errors?
How are the errors detected in read_only mode? Is there some checksum/CRC attached to each block?

Does it means I need to buy a new disk ASAP?

TIA,
kaza.

dc.901 · 11-21-2018, 07:19 AM

This is not a good sign:

Quote:

/var/log/messages-20181104:Oct 28 21:39:29 localhost kernel: print_req_error: critical target error, dev sdb, sector 7488278528
/var/log/messages-20181104:Oct 28 21:39:29 localhost kernel: sd 7:0:1:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
/var/log/messages-20181104:Oct 28 21:39:29 localhost kernel: sd 7:0:1:0: [sdb] tag#0 Sense Key : Hardware Error [current]
/var/log/messages-20181104:Oct 28 21:39:29 localhost kernel: sd 7:0:1:0: [sdb] tag#0 Add. Sense: Internal target failure
/var/log/messages-20181104:Oct 28 21:39:29 localhost kernel: sd 7:0:1:0: [sdb] tag#0 CDB: Read(16) 88 00 00 00 00 01 be 56 10 00 00 00 00 08 00 00
/var/log/messages-20181104:Oct 28 21:39:29 localhost kernel: print_req_error: critical target error, dev sdb, sector 7488278528

Bad sectors will grow, so yes, best bet to replace this disk (sooner than later).

If you want to do some additional testing; from one of your earlier posts:

Quote:

/bin/tar: /home/kaza/GRAPHICS/PICS/D/Video0025.3gp: File shrank by 4145152 bytes; padding with zeros
/home/kaza/GRAPHICS/PICS/D/Photo0271.jpg
/bin/tar: /home/kaza/GRAPHICS/PICS/D/Photo0271.jpg: Read error at byte 0, while reading 2048 bytes: Input/output error
/home/kaza/GRAPHICS/PICS/D/Photo0179.jpg
/bin/tar: /home/kaza/GRAPHICS/PICS/D/Photo0179.jpg: Read error at byte 0, while reading 3072 bytes: Input/output error
/home/kaza/GRAPHICS/PICS/D/Video0097.3gp
/bin/tar: /home/kaza/GRAPHICS/PICS/D/Video0097.3gp: Read error at byte 0, while reading 512 bytes: Input/output error

In your backup, if you exclude this directory: /home/kaza/GRAPHICS/PICS and everything under it, does it run?
Or, perhaps, exclude the entire 4TB disk - sdb, which is looks like mounted at /home/user/GRAPHICS
So, backup just the OS and see if you notice any hangups?

kaza · 11-21-2018, 01:43 PM

Thanks for the info,
I'm proceeding with replacement disk purchase.

The problematic disk is mounted on /home/kaza/GRAPHICS
and the data on it is MUCH more important than the OS.
The only reason I mamaged to complete the backup was by adding
to the tar exclude file the directory where I noticed the I/O errors
(from the tar log).

I already completed "verify" of the first set of 12 backup tapes,
and I'm currently in the middle of the backup on the second set
(I use 3 sets in rotation). By the time I'll get the shipment
of the disk and SAS cable I'll probably finish all 3 backups.

Now a question of pure curiocity: how could a disk with such an
enormous number of errors (842208107) work reasonably well?

I'm using it quite a lot: scan negatives onto it (from many years
of film photography), edit the images, download videos on it
and edit them, play videos from it. How all of these actions
not be impeded by bad sectors? BTW, as an example I viewed
one of the videos for which there were I/O errors during tar backup
and it looked OK for its entire length, I thought few bad sectors would
cause the video player to crash ot to exit with some "unrecognized format"
error.

Thanks for all of the replyes,
kaza.