Not that it answers your question but ext3 might not be best for a flash device as it could "wear out" some of the blocks.
http://osdir.com/ml/linux.ports.arm.general/2004-10/msg00084.html On Sat, 16 Jun 2007, Miernik wrote: > 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? > > -- /------------------------------------+-------------------------\ |Stephen J. Gowdy, SLAC | CERN Office: 32-2-A22| |http://www.slac.stanford.edu/~gowdy/ | CH-1211 Geneva 23 | |http://calendar.yahoo.com/gowdy | Switzerland | |EMail: [EMAIL PROTECTED] | Tel: +41 22 767 5840 | \------------------------------------+-------------------------/ ------------------------------------------------------------------------- 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
