Gfrktyl

I have an interesting problem on my home file/media server that I can't track down(debian 8.11). I am constantly seeing the following message in dmesg for the last few days:

Buffer I/O error on device sdg, logical block 5

Sometime I'll get a bit more in the logs

[331645.357795] Buffer I/O error on device sdg, logical block 7

[331826.255867] sd 14:0:0:0: [sdg] Command timed out

[331826.255875] sd 14:0:0:0: [sdg]  

[331826.255879] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

[331826.255883] sd 14:0:0:0: [sdg]  

[331826.255886] Sense Key : Not Ready [current] 

[331826.255892] sd 14:0:0:0: [sdg]  

[331826.255896] Add. Sense: Logical unit is in process of becoming 

ready

[331826.255899] sd 14:0:0:0: [sdg] CDB: 

[331826.255902] Read(10): 28 00 00 00 00 00 00 00 01 00

[331826.255915] end_request: I/O error, dev sdg, sector 0

[331826.257606] Buffer I/O error on device sdg, logical block 0

[331833.213945] sd 14:0:0:0: timing out command, waited 180s

[331833.215687] sd 14:0:0:0: [sdg] Command timed out

[331833.215692] sd 14:0:0:0: [sdg]  

[331833.215695] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

[331833.215699] sd 14:0:0:0: [sdg]  

[331833.215701] Sense Key : Not Ready [current] 

[331833.215717] sd 14:0:0:0: [sdg]  

[331833.215731] Add. Sense: Logical unit is in process of becoming 

ready

[331833.215735] sd 14:0:0:0: [sdg] CDB: 

[331833.215737] Read(10): 28 00 00 00 00 01 00 00 07 00

The problem is, I can't find a figure out what device sdg is?!?!

I am assuming it's block device of some sort, however there are only 6 physical drives in my server(sda, sdb, sdc, sdd, sde, sdf)

• sda = OS installation drive. Physical disk.


• sdb & sdc - MDADM RAID 0 as /dev/md1. Physical disks.


• sdd & sde - MDADM RAID 0 as /dev/md0. Physical disks.


• sdf - External USB drive used for nightly backups.

I've tried running fdisk -l /dev/sdg and the command just hangs.

ls -all /dev/disk/by-id/ | grep sdg returns 0 results.

I plugged in a USB thumb drive and it mounted as /dev/sdh, so it skipped /dev/sdg for some reason.

smartctl -a /dev/sdg returns the following:

smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.16.0-4-amd64] (local 

build)

Copyright (C) 2002-14, Bruce Allen, Christian Franke, 

www.smartmontools.org



Read Device Identity failed: scsi error device will be ready soon



A mandatory SMART command failed: exiting. To continue, add one or 

more '-T permissive' options.

cat /proc/diskstats returns:

   8      96 sdg 596 867 1458 163968604 0 0 0 0 1 68509944 164194776

There is nothing in /etc/fstab referencing /dev/sdg.

Other than running samba/ssh for sharing files on my home network, the only other application installed is Plex media server, however I wouldn't think any of those applications would be creating block devices on my system.

It's a bit of a relief to know that it's not any of my disks holding my data that are throwing errors, but now the question is how do I figure out what sdg is and why is it throwing these errors?

Any ideas on how I track this sdg drive down?

In theory lsblk -O /dev/sdg should tell you a lot. There are two problems though:

1. Faulty device may report little anyway.


2. 
   

   Usually the output of lsblk -O is cryptic because long lines get wrapped in the terminal, the entire output becomes unreadable. To overcome this:

   
   
   
   
   
   • 
     

     use a pager with handy horizontal scrolling, e.g.:

     
     
     

     lsblk -O /dev/sdg | less -S -# 8
     
     

     
     
   
   

   • or redirect to a file (lsblk -O /dev/sdg >/tmp/lsblk_sdg) and examine the file in any editor that can show non-wrapped lines and scrolls properly;

   
   
   • or view few columns at a time, like lsblk -o VENDOR,MODEL,SERIAL (run lsblk --help to know all available columns).
   
   
   
   

Alternatively cd to /sys/class/block/sdg/device and see what you can find (e.g. cat model). Again, if the device is faulty, you may not be able to retrieve much information.

Additionally find entries in dmesg (or in logs) from when the device was first discovered after reboot. They may or may not tell you something.