Linux
|
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 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. There is some discussion of bad outcomes with USB 'sticks' on this Big Copy to USB 'pen drives' page. 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
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.
< Go to Top of Page, above. >
|