On Wed, Jul 29, 2009 at 9:54 AM, Emil Pedersen<emil.peder...@its.uu.se> wrote: > Don't know if it is at all related, but I had some usb sticks > behaving quiet strange too (on a debian etch 64bit). > > The symptons where that a file (kernel actually) that was copied > to the stick could not be run the next time the stick was mounted. > Now the nasty part was that if I used e.g. tar or dd to put the > file on stick instead of cp the file _was_ correct after a remount. > > I also noticed that it took signicifantly longer to use tar than > cp (though perhaps tar is writing chars instead of blocks which > could explain that?). > > I never found out what was causing the behaviour, so please share > any findings to your problem.
For anyone who's interested, here's what we've been able to figure out so far. Apparently we were dealing with two unrelated problems, which caused a lot of my confusion. First, the Linux kernel does appear to have a bug that causes filesystem corruption when executing the following commands: mke2fs -O has_journal,resize_inode,dir_index,filetype,sparse_super,large_file /dev/sdb2 tune2fs -c 29 /dev/sdb2 # /dev/sdb is an external flash drive mount /dev/sdb2 /mnt/image cd /mnt/image tar xf ~/data.tar # data.tar is a 71MB archive of the /var partition cd umount /mnt/image e2fsck -f /dev/sdb2 The specific corruption that I've seen is that some symlinks are invalid; I don't know if other corruption is possible or not. Workarounds are to use ext2 or to mount -o sync. I can reproduce bug in Debian 4.0 and 5.0 but not Ubuntu 9.04 running off of a live CD on the same hardware, so I'm assuming that the problem was fixed between Debian 5.0's Linux 2.6.26 and Ubuntu 9.04's 2.6.28. I'm not sure the best way to further track down the problem from here. Is there an easy way (short of compiling my own kernel) to try out 2.6.27? If I submit a bug to Debian's bug tracker, would the Debian devs have the time and resources to backport a fix, or would this be a "wait until next release" problem? Second, the particular flash drive that we're using (Lexar JumpDrive Firefly 4GB, revision L) is apparently very unreliable under Linux, even though a previous revision of the same product worked fine. (We happened to start using the new revision flash drive around the same time that we upgraded to Debian 5.0. I didn't even notice that the revision had changed and so I mistakenly thought the problem was the Debian 5.0 upgrade.) The new revision is also 15% slower than the old revision. We tried contacting Lexar's tech support, but they claim that their product doesn't work under Linux. I don't know how to further troubleshoot this problem or why the flash drives work fine under Windows, but at this point, I'm probably just going to switch to a different manufacturer rather than sink more time into troubleshooting. Josh Kelley -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
