I recently bought 2 different USB flash disks. These are some cheap no-name
devices. Their parameters:
bytes C/H/S ID
4194304512 509/255/63 Vendor: Generic Model: USB Flash Drive Rev: 1.00 ANSI SCSI revision: 02
4288676352 1023/132/62 Vendor: USB Model: USB 2.0 Rev: 1.00 ANSI SCSI revision: 02
When I put a FAT32 filesystem on them, everything is OK, but when I put an ext3
filesystem, everything is OK when I write files to the disk, I can fill it with
files, but then when I remove the disk from the computer (after a proper
umount) and putting it in again, most of the files have corrupted direcotry
entries (they look red in midnight commander, some of them pink). But some
(about 5 to 10%) files are normal, and normally accessible.
I tried them both on two completely different computers with very different
hardware, and different Linux versions, and the effect is the same.
One of the computers is a desktop with and old AMD K7 Clayton motherboard with
only old USB1.1: VT82xxxxx UHCI USB 1.1 Controller, and Debian sid with
2.6.18-4-k7 kernel from Debian.
The other computer is a much newer AMD Athlon64 HP laptop with USB2.0 port and
SuSE 10.2.
Did anyone observe anything similar with any USB flash drives (FAT OK, ext3
corrupted)?
I've put files on these disks on FAT32 and run fsck.vfat, and everything looks
fine:
root@tarnica:~# dosfsck -v /dev/sda1
dosfsck 2.11 (12 Mar 2005)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "mkdosfs"
Media byte 0xf8 (hard disk)
512 bytes per logical sector
4096 bytes per cluster
32 reserved sectors
First FAT starts at byte 16384 (sector 32)
2 FATs, 32 bit entries
4177920 bytes per FAT (= 8160 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 8372224 (sector 16352)
1044477 data clusters (4278177792 bytes)
62 sectors/track, 132 heads
0 hidden sectors
8372170 sectors total
Checking for unused clusters.
Checking free cluster summary.
/dev/sda1: 121 files, 116397/1044477 clusters
root@tarnica:~# echo "$?"
0
root@tarnica:~#
With FAT I can read any file I saved to the disk just fine, it
simply works.
Maybe you'd like my 'lsusb -v' (this is on the USB1.1-only Debian machine):
Bus 002 Device 001: ID 0000:0000
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed hub
bMaxPacketSize0 64
idVendor 0x0000
idProduct 0x0000
bcdDevice 2.06
iManufacturer 3 Linux 2.6.18-4-k7 uhci_hcd
iProduct 2 UHCI Host Controller
iSerial 1 0000:00:07.3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 2
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0300 lowspeed power
Port 2: 0000.0300 lowspeed power
Device Status: 0x0003
Self Powered
Remote Wakeup Enabled
Bus 001 Device 002: ID 1043:8012 iCreate Technologies Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1043 iCreate Technologies Corp.
idProduct 0x8012
bcdDevice 1.00
iManufacturer 1 USB
iProduct 2 USB 2.0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
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 0x0040 1x 64 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 0x0040 1x 64 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
Bus 001 Device 001: ID 0000:0000
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed hub
bMaxPacketSize0 64
idVendor 0x0000
idProduct 0x0000
bcdDevice 2.06
iManufacturer 3 Linux 2.6.18-4-k7 uhci_hcd
iProduct 2 UHCI Host Controller
iSerial 1 0000:00:07.2
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 2
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0103 power enable connect
Port 2: 0000.0100 power
Device Status: 0x0003
Self Powered
Remote Wakeup Enabled
Let me give you some more diag.
Here is what I did:
Having read that too large max_sectors sometimes gives problems, I did:
root@tarnica:~# echo "64" > /sys/block/sda/device/max_sectors
But before I tried without reducing max_sectors from the default - no
difference.
root@tarnica:~# mkfs.ext3 /dev/sda1
mke2fs 1.40-WIP (07-Apr-2007)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
523264 inodes, 1046521 blocks
52326 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1073741824
32 block groups
32768 blocks per group, 32768 fragments per group
16352 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 24 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
root@tarnica:~# mount /dev/sda1 /mnt/sda1
No errors up till here.
root@tarnica:~# cp -dr /usr/share/doc/ /mnt/sda1/
Here we get this error in kern.log:
Jun 16 00:47:09 tarnica kernel: scsi0: PCI error Interrupt at seqaddr = 0x8
Jun 16 00:47:09 tarnica kernel: scsi0: Data Parity Error Detected during address or write data phase
root@tarnica:~# sync
Later I did an 'find -ls' in the /mnt/sda1/ directory,
then 'umount /mnt/sda1' and then 'mount /dev/sda1 /mnt/sda1' again.
The above commands caused that to appear in the output of 'dmesg':
EXT3-fs error (device sda1): ext3_readdir: bad entry in directory #11: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
Aborting journal on device sda1.
EXT3-fs error (device sda1) in ext3_ordered_writepage: IO failure
ext3_abort called.
EXT3-fs error (device sda1): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
EXT3-fs error (device sda1): ext3_readdir: bad entry in directory #11: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
EXT3-fs error (device sda1): ext3_readdir: bad entry in directory #11: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_committed_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_committed_data
kjournald starting. Commit interval 5 seconds
EXT3-fs warning (device sda1): ext3_clear_journal_err: Filesystem error recorded from previous mount: IO failure
EXT3-fs warning (device sda1): ext3_clear_journal_err: Marking fs in need of filesystem check.
EXT3-fs warning: mounting fs with errors, running e2fsck is recommended
EXT3 FS on sda1, internal journal
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
At this point:
root@tarnica:~# ls -al /mnt/sda1
total 24
drwxr-xr-x 4 root root 4096 2007-06-16 00:47 .
drwxr-xr-x 27 root root 4096 2007-06-09 09:25 ..
drwx------ 2 root root 16384 2007-06-16 00:37 lost+found
?--------- ? ? ? ? ? /mnt/sda1/doc
root@tarnica:~#
So I did 'umount /mnt/sda1' and 'e2fsck -v -y /dev/sda1', which runs endlessly
with a zillion errors, for example:
Inode 133561 has compression flag set on filesystem without compression support. Clear? yes
Inode 133561 has illegal block(s). Clear? yes
Illegal block #0 (189057594) in inode 133561. CLEARED.
Illegal block #1 (3559149010) in inode 133561. CLEARED.
Illegal block #2 (4279737499) in inode 133561. CLEARED.
Illegal block #3 (362979125) in inode 133561. CLEARED.
Illegal block #4 (3152073428) in inode 133561. CLEARED.
Illegal block #5 (679595262) in inode 133561. CLEARED.
Illegal block #6 (1924390837) in inode 133561. CLEARED.
Illegal block #7 (1058295063) in inode 133561. CLEARED.
Illegal block #8 (795243680) in inode 133561. CLEARED.
Illegal block #9 (3130620932) in inode 133561. CLEARED.
Illegal block #10 (1544529913) in inode 133561. CLEARED.
Too many illegal blocks in inode 133561.
Clear inode? yes
or:
Inode 134287 has compression flag set on filesystem without compression support. Clear? yes
Inode 134287, i_size is 7400753060221116605, should be 0. Fix? yes
Inode 134287, i_blocks is 2017258698, should be 0. Fix? yes
Inode 134303 has compression flag set on filesystem without compression support. Clear? yes
Inode 134303, i_size is 7400753060221116605, should be 0. Fix? yes
Inode 134303, i_blocks is 2017258698, should be 0. Fix? yes
or:
Inode 132391 has imagic flag set. Clear? yes
Special (device/socket/fifo) inode 132391 has non-zero size. Fix? yes
Inode 132392 is in use, but has dtime set. Fix? yes
Inode 132392 has imagic flag set. Clear? yes
and other different types of errors alternatively, from time to time
doing:
Restarting e2fsck from the beginning...
/dev/sda1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
and it seems this goes on forever. Nothing shows in 'dmesg', nor
kern.log nor 'cat /proc/kmsg' nor any other log file/output during doing
the filesystem check.
I would think it's a broken hardware, but this happens on two different
4 GB USB sticks, from two different sources, one used, one new, on
different computers, so it's quite unlikely that both of these sticks
would be bad. Besides that they work perfectly with FAT32. And it is
also unlikely that so different USB controllers on two different
computers would be bad at the same time.
Similar symptoms are in this bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404486
But I have never saw such symptoms using HDDs, CF cards (also 4 GB ones, on the
same machine) and 256 MB USB flash disks.
Any clues?
--
Miernik
http://miernik.name/
_______________________________________________
Ext3-users mailing list
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users
