Linux

Disk Partition Checking/Recovery

with 'fsck'

on an 'external' USB disk drive

(Symptoms , Solution)

Home > RefInfo menu > Computer topics menu >

This Disk-Partition-Checking/Recovery-with-'fsck' page

A few more screenshots or notes or links may be added,
if I revisit this page.

INTRODUCTION :

In May 2017, I was using an 'rsync' script (like one described on my rsync script page) to 'incrementally' back up (that is, synchronize) a directory from one 'external' USB disk drive to another.

    I was working on my desktop computer which had the old 2009-era Ubuntu 9.10 (Karmic Koala) operating system installed. It was using the Gnome 2 desktop environment, with the Nautilus file-manager.

    I had formatted these 2 'external' USB disk drives --- as 'ext3' Linux file systems, instead of Microsoft file systems --- using a technique described at my Linux Disk (Re)Formatting web page --- using the Nautilus 'Format' dialog panel that is displayed at the top of that page.

The 'rsync' command starting coughing up lots of errors and the 'rsync' command quit prematurely --- or hung up. (Unfortunately, I did not do a screen capture of the window showing the messages coming from the 'rsync' command --- so I cannot report more accurately on the exact text of the error messages.)

I tried copying a sub-directory of the 'source' directory of the 'from' drive to the 'target' directory on the 'to' drive --- using the GUI interfaces of the Gnome2-Nautilus file manager.

    I right-clicked on the 'source' subdirectory in a Nautilus file-manager window that was positioned in the 'source' disk file system ---- and chose 'Copy'.

    Then I right-clicked on the 'target' directory in a second Nautilus file-manager window that was positioned in the 'target' disk file system --- and chose 'Paste'.

    To my chagrin, the Nautilus 'copy' window that popped up started indicating the number of files to be copied and, after indicating how many files were to be copied, started showing the 'progress bar' on the 'copy' window .... BUT something was dreadfully wrong.

    Some 'progress numbers' that were showing up were indicating there were millions of files to be copied to the 'target' drive --- when there were more like 45,000. (Unfortunately, I did not do a screen capture of the copy-progress window so that I could report more accurately on the nature of the 'Copy' window messages.)

In any case, the various messages indicated that there was a problem with the 'target' external USB disk drive.

It turned out that the 'target' drive was not totally corrupt. I could right-click on the icon for the drive (that was on my Gnome2-Nautilus desktop) and choose 'Safely Remove Drive'. The icon disappeared as expected, and I unplugged the USB cable of the drive.

When I plugged-in the drive again, after about 20 seconds, the icon for the drive would re-appear on the desktop. And I could display the top level directories of the drive in the Nautilus file-manager GUI.

I had never used the 'fsck' command before to try to repair a file system, but I figured that the 'fsck' command was probably my only hope to repair this file system and still be able to use this 'target' disk drive --- which, by the way, was a 250 GB Western Digital My Passport 'external' USB disk drive that I had bought at a Target store on 17 Jul 2011 for $30.

    Not that it makes any difference, but for the record:
    The 'source' disk drive that I was trying to 'rsync' with was also a Western Digital My Passport 'external' USB disk drive --- but 320 GB, and bought at a BestBuy store on 12 Dec 2011.


The Search for a Solution:

I was able to start up my favorite web browser, Seamonkey, and do some Google searches on keywords like

Some of the 'hits' that I got were forum-pages and articles with titles like:

Some of the 'hits' explain how to find which /dev/sdX (like /dev/sdc1) to use with the 'fsck' command --- pages with titles like:

I provide a collection of some of the ways to get a /dev partition name in a 'More ways to query storage partitions' section below.

For now ...


Solution:

To make a long story short, in the 'checking an external hard drive for errors' page - at ubuntuforums.org - the following (abbreviated) commands/steps.


   df -h

   sudo umount /dev/sdX    (you'll see the letter for that from df -command)

   sudo fsck /dev/sdX

   then disconnect and plug it back --- or use

   sudo mount /dev/sdX /media/YourMount/Point

were suggested by person with the nickname 'bioterror'. As scary as that nickname sounds, his advice was just what I needed --- with a few details added.

Some of the other pages (the 'hits' above) indicated that it was very important to do the unmount before using 'fsck' --- otherwise the file system could be permanently damaged.

Furthermore, at least one of the other pages pointed out that the '-M' option of 'fsck' could be used as a safeguard.

In other words, a command like

sudo fsck -M ... /dev/sdX

could be used to make 'fsck' quickly terminate if the partition was still mounted.

Furthermore, another page indicated that the '-y' option of the 'fsck' command could be used to automatically reply 'y' to all prompts from the 'fsck' command when 'fsck' asked if it was OK to do a suggested action.

And to do a disk blocks check, one could use the '-c' option to check blocks and fix block errors.

Ultimately, I decided to do the following commands:


   df -h             (to determine the partition that the drive was mounted to)
   umount /dev/sdd1  (when 'df' showed that 'sdd1' was the partition)
   df -h             (to check if the 'umount' command was successful)
   fsck -M -y -c /dev/sdd1      (using '-M' to be extra careful)

You can see the commands that I used in a 'gnome-terminal' window --- in the following image:

It turned out the block checking was going to proceed at about 1% of the disk per minute --- so it was going to take over an hour and a half to do the block-checking part of the 'fsck' command on this 250 GB external USB disk drive.

The following image indicates that after it was done doing the block checking, the 'fsck' process was restarted --- which took at least another couple of hours:

Note that many 'illegal blocks' were found in various 'inodes' (more inodes than I could determine from scrolling a few hundred lines up the terminal window ... probably hundreds of inodes, if not thousands). And, apparently, the illegal blocks were 'CLEARED'.

The 'top' command, running in the lower terminal window, indicated that the 'badblocks' command was being used to check for bad blocks.

Note that 'fsck' detected that an 'ext3' file system is involved, and it uses the 'e2fsck' program, whose 'man' page says that 'e2fsck' is used to "check a Linux ext2/ext3/ext4 file system".

Also from the 'man e2fsck' command:



  -c     This option causes e2fsck to use badblocks(8) program to do a  read-
         only scan of the device in order to find any bad blocks.  If any bad
         blocks are found, they are added to the bad block inode  to  prevent
         them from being allocated to a file or directory.  If this option is
         specified twice, then the bad block scan will be done using  a  non-
         destructive read-write test.


The following image shows that the '-y' option is causing the 'Fix?' questions to be automatically answered with a 'y' response.

This image also shows that the 'fsck' command seems to have completed without any summary errors at the end. I thought 'THIS IS A GOOD SIGN'.

At this point, I decided to test this 'hopefully-fixed' disk partition by running the 'rsync' script again --- to synchronize a 'from' directory on one external USB drive to a 'to' directory on this 'hopefully-fixed' external USB drive.

The 'rsync' command ran for quite a few minutes, and the messages from the 'rsync' command indicated that there were a lot of files that needed to be copied to the 'to' directory.

The following image shows the number of files on (and the size of) the 'target' external USB drive when the 'rsync' was done.

This indicated to me that the 'fsck' fixing did not consume a lot of the disk space. There was still about 154 GB of 'free space' on this removable disk drive.

---------

I also right-clicked on the name of the 'to' directory of the 'rsync', using the Nautilus file manager, and I chose the 'Properties' option in the popup menu that appeared.

The files-count and the space-used numbers matched the numbers that I saw when I did the same 'Properties' query on the 'from' directory of the 'source' external USB disk drive.

WHAT A RELIEF! It seems that both the 'fsck' and the 'rsync' worked. I was back at a useful 250 GB external disk drive (well, actually 229.2 GB) --- from one that seemed to have major, major problems.

That said, I probably should occasionally do commands like the following for my various external USB storage drives:


   df -h             (to determine the partition that the drive was mounted to)
   umount /dev/sdd1  (when 'df' shows that 'sdd1' was the partition)
   df -h             (to check if the 'umount' command was successful)
   fsck -M -y /dev/sdd1      (using '-M' to be extra carefu - and using '-c' for block checking)

More ways to query storage partitions:

In looking through the many web pages that I got from the web searches that I mentioned above, I found a lot of ways that one can check on mounted disk drives --- in particular, their mount-directory names and their device-partition names.

Most of these are more awkward to use that the simple 'df -h' or 'df' command. But I list them here for my future reference --- and in case they may be useful to others who may read this page.

---------

Many pages suggested using the command

sudo fsdisk -l

but I think the 'df -h' command (or simply 'df') is easier to use. (You do not have to respond to a password prompt.)

Here is an example of output from the 'sudo fdisk -l' command, when a 320 GB external USB disk drive was plugged into my desktop computer. This output shows that that drive was automounted to '/dev/sdd1'.

Note that I have two 80 GB hard disk drives on this desktop computer --- /dev/sdb and /dev/sda --- one for mounting the /home directory and the other for the remaining directories of the root directory.

    An image above of the output from the 'df -h' command shows that the root directory is mounted to '/dev/sda1' and the /home directory is mounted to '/dev/sdb5'.


$ sudo fsdisk -l
[sudo] password for [userid shows here]: 

Disk /dev/sdb: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000a18a8

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1        9729    78148161    5  Extended
/dev/sdb5               1        9729    78148129+  83  Linux

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0009ff4b

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        9437    75802671   83  Linux
/dev/sda2            9438        9729     2345490    5  Extended
/dev/sda5            9438        9729     2345458+  82  Linux swap / Solaris

Disk /dev/sdd: 320.0 GB, 320044269568 bytes
255 heads, 63 sectors/track, 38909 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0006f604

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1       38910   312542208    7  HPFS/NTFS

Note that 'sdd1' is indeed listed, but this is not as easily readable as the 'df' command output.

Futhermore, this is misleading. It looks like this drive may be formatted as a Microsoft 'NTFS' file system, when it is a Linux 'ext3' file system.

---------

One page I found suggested using the command

cat /proc/partitions

as an alternative to 'sudo fdisk -l'.

Sample output from 'cat /proc/partitions' :


major minor  #blocks  name

   8       16   78150744 sdb
   8       17          1 sdb1
   8       21   78148129 sdb5
   8        0   78150744 sda
   8        1   75802671 sda1
   8        2          1 sda2
   8        5    2345458 sda5
   8       48  312543232 sdd
   8       49  312542208 sdd1

Note that 'sdd1' is indeed listed. However it is not readily apparent the size of that disk partition in gigabytes.

---------

Some web pages suggested using the 'mount' command. When I tried it, I got :


/dev/sda1 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
/dev/sdb5 on /home type ext3 (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
gvfs-fuse-daemon on /home/blaze/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=blaze)
/dev/sdd1 on /media/wd320GmyPassport type ext3 (rw,nosuid,nodev,uhelper=devkit)

This is not nearly as 'clean' as the 'df' command --- but it DID show the USB drive mounted on '/dev/sdd1', on the last line.

---------

Quite a few web pages suggested using the 'lsblk' command. But when I tried it, I got :


No command 'lsblk' found, did you mean:
 Command 'lslk' from package 'lslk' (universe)
lsblk: command not found

I did not bother to try to install it. There were many alternatives.

---------

Some pages suggested using

ls -l /dev/disk/by-id/usb*

OR

ls -l /dev/disk/by-id

OR

ls -lR /dev/disk

Here are outputs from those 3 commands:


$ ls -l /dev/disk/by-id/usb*
lrwxrwxrwx 1 root root  9 2017-06-02 10:01 /dev/disk/by-id/usb-EPSON_Storage_4E394E593236303688-0:0 -> ../../sdc
lrwxrwxrwx 1 root root  9 2017-06-02 13:17 /dev/disk/by-id/usb-WD_My_Passport_071A_575848314536314450594A31-0:0 -> ../../sdd
lrwxrwxrwx 1 root root 10 2017-06-02 13:17 /dev/disk/by-id/usb-WD_My_Passport_071A_575848314536314450594A31-0:0-part1 -> ../../sdd1

The EPSON USB device is my printer.


$ ls -l /dev/disk/by-id
total 0
lrwxrwxrwx 1 root root  9 2017-06-02 10:00 ata-ST380815AS_5QZ1TF60 -> ../../sda
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 ata-ST380815AS_5QZ1TF60-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 ata-ST380815AS_5QZ1TF60-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 ata-ST380815AS_5QZ1TF60-part5 -> ../../sda5
lrwxrwxrwx 1 root root  9 2017-06-02 10:00 ata-ST380815AS_5RX0DJL9 -> ../../sdb
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 ata-ST380815AS_5RX0DJL9-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 ata-ST380815AS_5RX0DJL9-part5 -> ../../sdb5
lrwxrwxrwx 1 root root  9 2017-06-02 10:00 scsi-SATA_ST380815AS_5QZ1TF60 -> ../../sda
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 scsi-SATA_ST380815AS_5QZ1TF60-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 scsi-SATA_ST380815AS_5QZ1TF60-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 scsi-SATA_ST380815AS_5QZ1TF60-part5 -> ../../sda5
lrwxrwxrwx 1 root root  9 2017-06-02 10:00 scsi-SATA_ST380815AS_5RX0DJL9 -> ../../sdb
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 scsi-SATA_ST380815AS_5RX0DJL9-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 scsi-SATA_ST380815AS_5RX0DJL9-part5 -> ../../sdb5
lrwxrwxrwx 1 root root  9 2017-06-02 10:01 usb-EPSON_Storage_4E394E593236303688-0:0 -> ../../sdc
lrwxrwxrwx 1 root root  9 2017-06-02 13:17 usb-WD_My_Passport_071A_575848314536314450594A31-0:0 -> ../../sdd
lrwxrwxrwx 1 root root 10 2017-06-02 13:17 usb-WD_My_Passport_071A_575848314536314450594A31-0:0-part1 -> ../../sdd1


$ ls -lR /dev/disk
/dev/disk:
total 0
drwxr-xr-x 2 root root 380 2017-06-02 13:17 by-id
drwxr-xr-x 2 root root  60 2017-06-02 13:17 by-label
drwxr-xr-x 2 root root 280 2017-06-02 13:17 by-path
drwxr-xr-x 2 root root 100 2017-06-02 13:17 by-uuid

/dev/disk/by-id:
total 0
lrwxrwxrwx 1 root root  9 2017-06-02 10:00 ata-ST380815AS_5QZ1TF60 -> ../../sda
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 ata-ST380815AS_5QZ1TF60-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 ata-ST380815AS_5QZ1TF60-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 ata-ST380815AS_5QZ1TF60-part5 -> ../../sda5
lrwxrwxrwx 1 root root  9 2017-06-02 10:00 ata-ST380815AS_5RX0DJL9 -> ../../sdb
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 ata-ST380815AS_5RX0DJL9-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 ata-ST380815AS_5RX0DJL9-part5 -> ../../sdb5
lrwxrwxrwx 1 root root  9 2017-06-02 10:00 scsi-SATA_ST380815AS_5QZ1TF60 -> ../../sda
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 scsi-SATA_ST380815AS_5QZ1TF60-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 scsi-SATA_ST380815AS_5QZ1TF60-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 scsi-SATA_ST380815AS_5QZ1TF60-part5 -> ../../sda5
lrwxrwxrwx 1 root root  9 2017-06-02 10:00 scsi-SATA_ST380815AS_5RX0DJL9 -> ../../sdb
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 scsi-SATA_ST380815AS_5RX0DJL9-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 scsi-SATA_ST380815AS_5RX0DJL9-part5 -> ../../sdb5
lrwxrwxrwx 1 root root  9 2017-06-02 10:01 usb-EPSON_Storage_4E394E593236303688-0:0 -> ../../sdc
lrwxrwxrwx 1 root root  9 2017-06-02 13:17 usb-WD_My_Passport_071A_575848314536314450594A31-0:0 -> ../../sdd
lrwxrwxrwx 1 root root 10 2017-06-02 13:17 usb-WD_My_Passport_071A_575848314536314450594A31-0:0-part1 -> ../../sdd1

/dev/disk/by-label:
total 0
lrwxrwxrwx 1 root root 10 2017-06-02 13:17 wd320GmyPassport -> ../../sdd1

/dev/disk/by-path:
total 0
lrwxrwxrwx 1 root root  9 2017-06-02 10:00 pci-0000:00:11.0-scsi-1:0:0:0 -> ../../sda
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 pci-0000:00:11.0-scsi-1:0:0:0-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 pci-0000:00:11.0-scsi-1:0:0:0-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 pci-0000:00:11.0-scsi-1:0:0:0-part5 -> ../../sda5
lrwxrwxrwx 1 root root  9 2017-06-02 10:00 pci-0000:00:11.0-scsi-2:0:0:0 -> ../../sdb
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 pci-0000:00:11.0-scsi-2:0:0:0-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 pci-0000:00:11.0-scsi-2:0:0:0-part5 -> ../../sdb5
lrwxrwxrwx 1 root root  9 2017-06-02 10:01 pci-0000:00:12.2-usb-0:4:1.2-scsi-0:0:0:0 -> ../../sdc
lrwxrwxrwx 1 root root  9 2017-06-02 13:17 pci-0000:00:12.2-usb-0:6:1.0-scsi-0:0:0:0 -> ../../sdd
lrwxrwxrwx 1 root root 10 2017-06-02 13:17 pci-0000:00:12.2-usb-0:6:1.0-scsi-0:0:0:0-part1 -> ../../sdd1
lrwxrwxrwx 1 root root  9 2017-06-02 10:00 pci-0000:00:14.1-scsi-0:0:0:0 -> ../../sr0
lrwxrwxrwx 1 root root  9 2017-06-02 10:00 pci-0000:00:14.1-scsi-0:0:1:0 -> ../../sr1

/dev/disk/by-uuid:
total 0
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 42e31ac2-1bfc-4573-9f15-66775148e00a -> ../../sda1
lrwxrwxrwx 1 root root 10 2017-06-02 13:17 9f56af24-90e6-4157-b426-a204ea5523f5 -> ../../sdd1
lrwxrwxrwx 1 root root 10 2017-06-02 10:00 bcc41238-f60d-4e0f-8315-062ca3c5f1e1 -> ../../sdb5

These commands DO indicate that the Western Digital (WD) drive is mounted on device 'sdd1'.

---------

Some web pages suggested using the 'lsusb' or 'lsusb -v' command. When I tried 'lsusb', I got :


Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 005: ID 1058:071a Western Digital Technologies, Inc. 
Bus 001 Device 003: ID 04b8:0884 Seiko Epson Corp. 
Bus 001 Device 002: ID 046d:0807 Logitech, Inc. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 046d:c246 Logitech, Inc. 
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

This DID indicate that the Western Digital USB drive was possibly accessible, but it does not show the '/dev' partition name.

By using 'lsusb -v | more', I could see the following info for the Western Digital device:


Bus 001 Device 005: ID 1058:071a Western Digital Technologies, Inc. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x1058 Western Digital Technologies, Inc.
  idProduct          0x071a 
  bcdDevice           20.19
  iManufacturer           1 
  iProduct                2 
  iSerial                 3 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0

This still does not show the '/dev' partition name.

---------

Some web pages pointed out that if the package 'smartmontools' is installed, the 'smartctl' command can be used on S.M.A.R.T. storage drives.

Examples using 'sdc' --- to check on possible imminent drive failure:


sudo smartctl -H /dev/sdc
(prints drive health data)

sudo smartctl -a /dev/sdc | more
(prints drive health data, attributes, and available test results)

sudo smartctl -t short /dev/sdc | more
     OR
sudo smartctl -t long /dev/sdc | more
(a short - few minutes - OR long - up to many hours - self test in background)

Some web pages suggested using the 'parted' command to get information about the drive --- like model, disk size, sector size, and file system type. But you need to know the /dev partition name. Example:


$ sudo parted /dev/sdd 'print'

Model: WD My Passport 071A (scsi)
Disk /dev/sdd: 320GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End    Size   Type     File system  Flags
 1      1049kB  320GB  320GB  primary  ext3

Note that although this says 'Partition Table: msdos', it says 'File system' is 'ext3'.

---------

Some web pages suggested using the 'hdparm' command to get information about the drive. But you need to know the /dev partition name.

Example 'hdparm' command output:


$ sudo hdparm -I /dev/sdd

/dev/sdd:

ATA device, with non-removable media
	Model Number:       WDC WD3200BMVV-11SXZS1                  
	Serial Number:      WD-WXH1E61DPYJ1
	Firmware Revision:  01.01A01
	Transport:          Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6
Standards:
	Supported: 8 7 6 5 
	Likely used: 8
Configuration:
	Logical		max	current
	cylinders	16383	16383
	heads		16	16
	sectors/track	63	63
	--
	CHS current addressable sectors:   16514064
	LBA    user addressable sectors:  268435455
	LBA48  user addressable sectors:  625142448
	Logical  Sector size:                   512 bytes
	Physical Sector size:                  4096 bytes
	Logical Sector-0 offset:                  0 bytes
	device size with M = 1024*1024:      305245 MBytes
	device size with M = 1000*1000:      320072 MBytes (320 GB)
	cache/buffer size  = 8192 KBytes
	Nominal Media Rotation Rate: 5400
Capabilities:
	LBA, IORDY(can be disabled)
	Queue depth: 32
	Standby timer values: spec'd by Standard, with device specific minimum
	R/W multiple sector transfer: Max = 16	Current = 0
	Advanced power management level: 128
	DMA: *mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 udma6 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
	Enabled	Supported:
	   *	SMART feature set
	    	Security Mode feature set
	   *	Power Management feature set
	   *	Write cache
	   *	Look-ahead
	   *	Host Protected Area feature set
	   *	WRITE_BUFFER command
	   *	READ_BUFFER command
	   *	NOP cmd
	   *	DOWNLOAD_MICROCODE
	   *	Advanced Power Management feature set
	    	SET_MAX security extension
	   *	48-bit Address feature set
	   *	Device Configuration Overlay feature set
	   *	Mandatory FLUSH_CACHE
	   *	FLUSH_CACHE_EXT
	   *	SMART error logging
	   *	SMART self-test
	   *	General Purpose Logging feature set
	   *	64-bit World wide name
	   *	IDLE_IMMEDIATE with UNLOAD
	   *	{READ,WRITE}_DMA_EXT_GPL commands
	   *	Segmented DOWNLOAD_MICROCODE
	   *	Gen1 signaling speed (1.5Gb/s)
	   *	Gen2 signaling speed (3.0Gb/s)
	   *	Native Command Queueing (NCQ)
	   *	Host-initiated interface power management
	   *	Phy event counters
	   *	Idle-Unload when NCQ is active
	   *	NCQ priority information
	    	DMA Setup Auto-Activate optimization
	    	Device-initiated interface power management
	   *	Software settings preservation
	   *	SMART Command Transport (SCT) feature set
	   *	SCT LBA Segment Access (AC2)
	   *	SCT Features Control (AC4)
	   *	SCT Data Tables (AC5)
	    	unknown 206[12] (vendor specific)
	    	unknown 206[13] (vendor specific)
	    	unknown 206[14] (vendor specific)
Security: 
	Master password revision code = 65534
		supported
	not	enabled
	not	locked
	not	frozen
	not	expired: security count
		supported: enhanced erase
	76min for SECURITY ERASE UNIT. 76min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 50014ee656ceaa96
	NAA		: 5
	IEEE OUI	: 0014ee
	Unique ID	: 656ceaa96
Checksum: correct

CONCLUSION:

It turned out that the commands 'df -h' and 'sudo fsck -M -y -c /dev/sdX' worked for me.

I was much relieved that these two relatively simple commands were sufficient to 'uncorrupt' my external USB disk drive that seemed to be in a really bad way.

---------

However, I must say that I have had a couple of USB storage 'sticks' that have been corrupted in the past --- and they were corrupted so badly that they would not 'automount' when I plugged them into a USB socket on my desktop or netbook computers.

So I was unable to find a '/dev/sdX' partition to use to 'restore' those USB 'sticks' to a functioning state.

Those sticks, I believe, were corrupted when I accidentally unplugged the drives when they had not been unmounted 'safely'.

One 'stick' was plugged into a Samsung TV --- and was probably being accessed by a Linux operating system in the Samsung TV. But it was not clear when it was safe to remove the (Verbatim) USB 'stick' from the TV. It may be that it is best to power down the TV before removing the 'stick'.

The other 'stick' was plugged into my desktop computer (with the Ubuntu 9.10 Linux operating system). I think I may have unplugged the (PNY) 'stick' before making sure I had right-clicked its icon on the desktop and chosen 'Safely Remove Drive' --- after an 'rsync' run.

I know one thing I have learned. USB 'sticks' are too 'touchy' to be used for reliable file backup of a large file system.

I think I will use 'external USB disk drives' rather than 'USB sticks' to backup large file systems. It seems that their controller systems are a little more robust than the USB controller on USB 'sticks'.

I actually saw a comment on one of the forums, when I was looking for info on 'fsck', that indicated similar concerns about the robustness of the control logic or control hardware on USB 'sticks'.

---------

Note that the two commands ('df' and 'fsck') that I used to recover the external USB disk drive are available on almost any Linux system.

So the technique described here would probably work on most other Linux 'distros' --- such as ones that use a KDE or Xfce or other 'desktop environment'.

The main thing is to be able to open a terminal window and issue the 'df' and 'fsck' commands.

Bottom of this
Disk Partition Checking with 'fsck' page.

To return to a previously visited web page location, click on the Back button of your web browser, a sufficient number of times. OR, use the History-list option of your web browser.
OR ...

< Go to Top of Page, above. >

Page was created 2017 Jun 01.

Page was changed 2018 Aug 31.
(Added css and javascript to try to handle text-size for smartphones, esp. in portrait orientation.)