On Fri, Jun 15, 2007 at 06:16:55PM -0400, Alan Stern wrote:
> Actually I'd be more interested in seeing if any error messages show
> up in the dmesg log when you try writing to the ext3 filesystem or
> when you unmount it.
OK, here is what I did:
Having read that too large max_sectors sometimes gives problems, I did:
[EMAIL PROTECTED]:~# echo "64" > /sys/block/sda/device/max_sectors
But before I tried without reducing max_sectors from the default - no
difference.
[EMAIL PROTECTED]:~# 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.
[EMAIL PROTECTED]:~# mount /dev/sda1 /mnt/sda1
No errors up till here.
[EMAIL PROTECTED]:~# 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
[EMAIL PROTECTED]:~# 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:
[EMAIL PROTECTED]:~# 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
[EMAIL PROTECTED]:~#
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.
Any clues?
--
Miernik
http://miernik.name/
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-usb-users@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
