Dear All,
I have an 8GB USB memory stick which I believe is faulty. I know
there are duff USB sticks out there on the market. The vendor assures
me that all items are checked before dispatch and so I would like to
demonstrate/verify the problem for him.

The device identifies its capacity as 8GB and will format OK (under
both WinXP PRO SP2 / FAT32 and Linux Ext2 & FAT32). The symptoms are
if less than ~2GB is used the data remains valid. If more than ~2GB
is used corrupt files result. Running badblocks in default write mode
(fills the whole device & then verifies, with in turn; 0xaa, 0x55,
0xff, 0x00) shows no errors but in random byte mode, beyond block
2059776 (ie. approx. 2GB) is flagged as bad.

Below is the set of tests I've used. Is there anything I've overlooked?

Thanks
Tom Crane.
--------------------------------------------------------------------------

# On inserting USB stick. Syslog kernel messages follow;
Jun 24 23:37:46 mklab kernel: usb 5-1: new high speed USB device using ehci_hcd and address 2
Jun 24 23:37:46 mklab kernel: usb 5-1: configuration #1 chosen from 1 choice
Jun 24 23:37:46 mklab kernel: scsi2 : SCSI emulation for USB Mass Storage devices
Jun 24 23:37:51 mklab kernel: scsi 2:0:0:0: Direct-Access Udisk Udisk 2.0 2.10 PQ: 0 ANSI: 2
Jun 24 23:37:51 mklab kernel: SCSI device sda: 16395736 512-byte hdwr sectors (8395 MB)
Jun 24 23:37:51 mklab kernel: sda: Write Protect is off
Jun 24 23:37:51 mklab kernel: SCSI device sda: 16395736 512-byte hdwr sectors (8395 MB)
Jun 24 23:37:51 mklab kernel: sda: Write Protect is off
Jun 24 23:37:51 mklab kernel: sda:
Jun 24 23:37:51 mklab kernel: sd 2:0:0:0: Attached scsi removable disk sda
Jun 24 23:37:51 mklab kernel: sd 2:0:0:0: Attached scsi generic sg0 type 0

cd /tmp
tmp$ dd if=/dev/urandom of=100MB.raw bs=100M count=1
1+0 records in
1+0 records out
104857600 bytes (105 MB) copied, 46.614 s, 2.2 MB/s
tmp$ md5sum 100MB.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 100MB.raw


tmp# fdisk -l /dev/sda
Disk /dev/sda: 8394 MB, 8394616832 bytes
64 heads, 32 sectors/track, 8005 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

Device Boot Start End Blocks Id System

tmp# time badblocks -vw /dev/sda
Checking for bad blocks in read-write mode
From block 0 to 8197868
Testing with pattern 0xaa: done
Reading and comparing: done
Testing with pattern 0x55: done
Reading and comparing: done
Testing with pattern 0xff: done
Reading and comparing: done
Testing with pattern 0x00: done
Reading and comparing: done
Pass completed, 0 bad blocks found.

real 107m56.476s
user 2m48.195s
sys 0m33.890s
tmp# time badblocks -vw -t random /dev/sda
Checking for bad blocks in read-write mode
From block 0 to 8197868
Testing with random pattern: done
Reading and comparing: 2059776
2059777
2059778
2059779
2059780
2059781
2059782
2059783
2059784
2059785
2059786
2059787
2059788
2059789
2059790
2059791
2059792
2059793
2059794
2059795
2059796
etc...

# Created a partition on the device.
tmp# fdisk -l /dev/sda

Disk /dev/sda: 8394 MB, 8394616832 bytes
64 heads, 32 sectors/track, 8005 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

Device Boot Start End Blocks Id System
/dev/sda1 1 8005 8197104 83 Linux

tmp# mke2fs /dev/sda1
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1026144 inodes, 2049276 blocks
102463 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2101346304
63 block groups
32768 blocks per group, 32768 fragments per group
16288 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Writing inode tables: 0/63 1/63 2/63 3/63 4/63 5/63 6/63 7/63 8/63
9/63 10/63 11/63 12/63 13/63 14/63 15/63 16/63 17/63 18/63 19/63 20/63
21/63 22/63 23/63 24/63 25/63 26/63 27/63 28/63 29/63 30/63 31/63
32/63 33/63 34/63 35/63 36/63 37/63 38/63 39/63 40/63 41/63 42/63
43/63 44/63 45/63 46/63 47/63 48/63 49/63 50/63 51/63 52/63 53/63
54/63 55/63 56/63 57/63 58/63 59/63 60/63 61/63 62/63 done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 31 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
tmp# mount /dev/sda1 /mnt/tmp

tmp# for ((i=0; i<15; i++)); do cp -v 100MB.raw /mnt/tmp/100MB.${i}.raw ; done
`100MB.raw' -> `/mnt/tmp/100MB.0.raw'
`100MB.raw' -> `/mnt/tmp/100MB.1.raw'
`100MB.raw' -> `/mnt/tmp/100MB.2.raw'
`100MB.raw' -> `/mnt/tmp/100MB.3.raw'
`100MB.raw' -> `/mnt/tmp/100MB.4.raw'
`100MB.raw' -> `/mnt/tmp/100MB.5.raw'
`100MB.raw' -> `/mnt/tmp/100MB.6.raw'
`100MB.raw' -> `/mnt/tmp/100MB.7.raw'
`100MB.raw' -> `/mnt/tmp/100MB.8.raw'
`100MB.raw' -> `/mnt/tmp/100MB.9.raw'
`100MB.raw' -> `/mnt/tmp/100MB.10.raw'
`100MB.raw' -> `/mnt/tmp/100MB.11.raw'
`100MB.raw' -> `/mnt/tmp/100MB.12.raw'
`100MB.raw' -> `/mnt/tmp/100MB.13.raw'
`100MB.raw' -> `/mnt/tmp/100MB.14.raw'
tmp# ls -la /mnt/tmp/*.raw
total 1537584
drwxr-xr-x 3 root root 4096 2008-06-25 03:10 .
drwxr-xr-x 6 root root 4096 2007-09-05 00:54 ..
-rw-r--r-- 1 root root 104857600 2008-06-25 03:00 100MB.0.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:00 100MB.1.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:07 100MB.10.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:08 100MB.11.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:09 100MB.12.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:10 100MB.13.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:11 100MB.14.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:00 100MB.2.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:01 100MB.3.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:02 100MB.4.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:03 100MB.5.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:04 100MB.6.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:05 100MB.7.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:05 100MB.8.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:06 100MB.9.raw
drwx------ 2 root root 16384 2008-06-25 02:59 lost+found
tmp# md5sum /mnt/tmp/*.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.0.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.1.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.10.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.11.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.12.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.13.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.14.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.2.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.3.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.4.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.5.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.6.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.7.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.8.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.9.raw

# unmounting & running e2fsck -f /dev/sda1 however reports
# many FS errors which cannot be repaired.
# reformatting and remounting
tmp# for ((i=0; i<70; i++)); do cp -v 100MB.raw /mnt/tmp/100MB.${i}.raw ; done
`100MB.raw' -> `/mnt/tmp/100MB.0.raw'
`100MB.raw' -> `/mnt/tmp/100MB.1.raw'
`100MB.raw' -> `/mnt/tmp/100MB.2.raw'
`100MB.raw' -> `/mnt/tmp/100MB.3.raw'
`100MB.raw' -> `/mnt/tmp/100MB.4.raw'
`100MB.raw' -> `/mnt/tmp/100MB.5.raw'
`100MB.raw' -> `/mnt/tmp/100MB.6.raw'
`100MB.raw' -> `/mnt/tmp/100MB.7.raw'
`100MB.raw' -> `/mnt/tmp/100MB.8.raw'
`100MB.raw' -> `/mnt/tmp/100MB.9.raw'
`100MB.raw' -> `/mnt/tmp/100MB.10.raw'
`100MB.raw' -> `/mnt/tmp/100MB.11.raw'
`100MB.raw' -> `/mnt/tmp/100MB.12.raw'
`100MB.raw' -> `/mnt/tmp/100MB.13.raw'
`100MB.raw' -> `/mnt/tmp/100MB.14.raw'
`100MB.raw' -> `/mnt/tmp/100MB.15.raw'
`100MB.raw' -> `/mnt/tmp/100MB.16.raw'
`100MB.raw' -> `/mnt/tmp/100MB.17.raw'
`100MB.raw' -> `/mnt/tmp/100MB.18.raw'
`100MB.raw' -> `/mnt/tmp/100MB.19.raw'
`100MB.raw' -> `/mnt/tmp/100MB.20.raw'
`100MB.raw' -> `/mnt/tmp/100MB.21.raw'
`100MB.raw' -> `/mnt/tmp/100MB.22.raw'
`100MB.raw' -> `/mnt/tmp/100MB.23.raw'
`100MB.raw' -> `/mnt/tmp/100MB.24.raw'
`100MB.raw' -> `/mnt/tmp/100MB.25.raw'
`100MB.raw' -> `/mnt/tmp/100MB.26.raw'
`100MB.raw' -> `/mnt/tmp/100MB.27.raw'
`100MB.raw' -> `/mnt/tmp/100MB.28.raw'
`100MB.raw' -> `/mnt/tmp/100MB.29.raw'
`100MB.raw' -> `/mnt/tmp/100MB.30.raw'
`100MB.raw' -> `/mnt/tmp/100MB.31.raw'
`100MB.raw' -> `/mnt/tmp/100MB.32.raw'
`100MB.raw' -> `/mnt/tmp/100MB.33.raw'
`100MB.raw' -> `/mnt/tmp/100MB.34.raw'
`100MB.raw' -> `/mnt/tmp/100MB.35.raw'
`100MB.raw' -> `/mnt/tmp/100MB.36.raw'
`100MB.raw' -> `/mnt/tmp/100MB.37.raw'
`100MB.raw' -> `/mnt/tmp/100MB.38.raw'
`100MB.raw' -> `/mnt/tmp/100MB.39.raw'
`100MB.raw' -> `/mnt/tmp/100MB.40.raw'
`100MB.raw' -> `/mnt/tmp/100MB.41.raw'
`100MB.raw' -> `/mnt/tmp/100MB.42.raw'
`100MB.raw' -> `/mnt/tmp/100MB.43.raw'
`100MB.raw' -> `/mnt/tmp/100MB.44.raw'
`100MB.raw' -> `/mnt/tmp/100MB.45.raw'
`100MB.raw' -> `/mnt/tmp/100MB.46.raw'
`100MB.raw' -> `/mnt/tmp/100MB.47.raw'
`100MB.raw' -> `/mnt/tmp/100MB.48.raw'
`100MB.raw' -> `/mnt/tmp/100MB.49.raw'
`100MB.raw' -> `/mnt/tmp/100MB.50.raw'
`100MB.raw' -> `/mnt/tmp/100MB.51.raw'
cp: writing `/mnt/tmp/100MB.51.raw': Input/output error
`100MB.raw' -> `/mnt/tmp/100MB.52.raw'
cp: writing `/mnt/tmp/100MB.52.raw': Input/output error
`100MB.raw' -> `/mnt/tmp/100MB.53.raw'
cp: writing `/mnt/tmp/100MB.53.raw': Input/output error
`100MB.raw' -> `/mnt/tmp/100MB.54.raw'
cp: writing `/mnt/tmp/100MB.54.raw': Input/output error
`100MB.raw' -> `/mnt/tmp/100MB.55.raw'
cp: writing `/mnt/tmp/100MB.55.raw': Input/output error
`100MB.raw' -> `/mnt/tmp/100MB.56.raw'
cp: writing `/mnt/tmp/100MB.56.raw': Input/output error
`100MB.raw' -> `/mnt/tmp/100MB.57.raw'
cp: writing `/mnt/tmp/100MB.57.raw': Input/output error
`100MB.raw' -> `/mnt/tmp/100MB.58.raw'
cp: writing `/mnt/tmp/100MB.58.raw': Input/output error
`100MB.raw' -> `/mnt/tmp/100MB.59.raw'
cp: writing `/mnt/tmp/100MB.59.raw': Input/output error
`100MB.raw' -> `/mnt/tmp/100MB.60.raw'
cp: writing `/mnt/tmp/100MB.60.raw': Input/output error
`100MB.raw' -> `/mnt/tmp/100MB.61.raw'
cp: writing `/mnt/tmp/100MB.61.raw': Input/output error
`100MB.raw' -> `/mnt/tmp/100MB.62.raw'
cp: writing `/mnt/tmp/100MB.62.raw': Input/output error
`100MB.raw' -> `/mnt/tmp/100MB.63.raw'
cp: writing `/mnt/tmp/100MB.63.raw': Input/output error
`100MB.raw' -> `/mnt/tmp/100MB.64.raw'
cp: writing `/mnt/tmp/100MB.64.raw': Input/output error
`100MB.raw' -> `/mnt/tmp/100MB.65.raw'
cp: writing `/mnt/tmp/100MB.65.raw': Input/output error
`100MB.raw' -> `/mnt/tmp/100MB.66.raw'
cp: writing `/mnt/tmp/100MB.66.raw': Input/output error
`100MB.raw' -> `/mnt/tmp/100MB.67.raw'
cp: writing `/mnt/tmp/100MB.67.raw': Input/output error
`100MB.raw' -> `/mnt/tmp/100MB.68.raw'
cp: writing `/mnt/tmp/100MB.68.raw': Input/output error
`100MB.raw' -> `/mnt/tmp/100MB.69.raw'
cp: writing `/mnt/tmp/100MB.69.raw': Input/output error
tmp# ls -la /mnt/tmp
total 5325956
drwxr-xr-x 3 root root 4096 2008-06-25 03:45 .
drwxr-xr-x 6 root root 4096 2007-09-05 00:54 ..
-rw-r--r-- 1 root root 104857600 2008-06-25 03:22 100MB.0.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:22 100MB.1.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:29 100MB.10.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:30 100MB.11.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:31 100MB.12.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:32 100MB.13.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:33 100MB.14.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:34 100MB.15.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:35 100MB.16.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:36 100MB.17.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:36 100MB.18.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:39 100MB.19.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:23 100MB.2.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:39 100MB.20.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:39 100MB.21.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:40 100MB.22.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:40 100MB.23.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:40 100MB.24.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:40 100MB.25.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:40 100MB.26.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:40 100MB.27.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:41 100MB.28.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:41 100MB.29.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:24 100MB.3.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:41 100MB.30.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:41 100MB.31.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:41 100MB.32.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:42 100MB.33.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:42 100MB.34.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:42 100MB.35.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:42 100MB.36.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:42 100MB.37.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:43 100MB.38.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:43 100MB.39.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:24 100MB.4.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:43 100MB.40.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:43 100MB.41.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:43 100MB.42.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:44 100MB.43.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:44 100MB.44.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:44 100MB.45.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:44 100MB.46.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:44 100MB.47.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:44 100MB.48.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:45 100MB.49.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:25 100MB.5.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:45 100MB.50.raw
-rw-r--r-- 1 root root 100483072 2008-06-25 03:45 100MB.51.raw
-rw-r--r-- 1 root root 0 2008-06-25 03:45 100MB.52.raw
-rw-r--r-- 1 root root 0 2008-06-25 03:45 100MB.53.raw
-rw-r--r-- 1 root root 0 2008-06-25 03:45 100MB.54.raw
-rw-r--r-- 1 root root 0 2008-06-25 03:45 100MB.55.raw
-rw-r--r-- 1 root root 0 2008-06-25 03:45 100MB.56.raw
-rw-r--r-- 1 root root 0 2008-06-25 03:45 100MB.57.raw
-rw-r--r-- 1 root root 0 2008-06-25 03:45 100MB.58.raw
-rw-r--r-- 1 root root 0 2008-06-25 03:45 100MB.59.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:26 100MB.6.raw
-rw-r--r-- 1 root root 0 2008-06-25 03:45 100MB.60.raw
-rw-r--r-- 1 root root 0 2008-06-25 03:45 100MB.61.raw
-rw-r--r-- 1 root root 0 2008-06-25 03:45 100MB.62.raw
-rw-r--r-- 1 root root 0 2008-06-25 03:45 100MB.63.raw
-rw-r--r-- 1 root root 0 2008-06-25 03:45 100MB.64.raw
-rw-r--r-- 1 root root 0 2008-06-25 03:45 100MB.65.raw
-rw-r--r-- 1 root root 0 2008-06-25 03:45 100MB.66.raw
-rw-r--r-- 1 root root 0 2008-06-25 03:45 100MB.67.raw
-rw-r--r-- 1 root root 0 2008-06-25 03:45 100MB.68.raw
-rw-r--r-- 1 root root 0 2008-06-25 03:45 100MB.69.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:27 100MB.7.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:28 100MB.8.raw
-rw-r--r-- 1 root root 104857600 2008-06-25 03:29 100MB.9.raw
drwx------ 2 root root 16384 2008-06-25 03:21 lost+found
tmp# df -h /mnt/tmp
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 7.7G 5.1G 2.3G 70% /mnt/tmp
tmp# md5sum /mnt/tmp/*.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.0.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.1.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.10.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.11.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.12.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.13.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.14.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.15.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.16.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.17.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.18.raw
md5sum: /mnt/tmp/100MB.19.raw: Input/output error
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.2.raw
md5sum: /mnt/tmp/100MB.20.raw: Input/output error
md5sum: /mnt/tmp/100MB.21.raw: Input/output error
md5sum: /mnt/tmp/100MB.22.raw: Input/output error
md5sum: /mnt/tmp/100MB.23.raw: Input/output error
md5sum: /mnt/tmp/100MB.24.raw: Input/output error
md5sum: /mnt/tmp/100MB.25.raw: Input/output error
md5sum: /mnt/tmp/100MB.26.raw: Input/output error
md5sum: /mnt/tmp/100MB.27.raw: Input/output error
md5sum: /mnt/tmp/100MB.28.raw: Input/output error
md5sum: /mnt/tmp/100MB.29.raw: Input/output error
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.3.raw
md5sum: /mnt/tmp/100MB.30.raw: Input/output error
md5sum: /mnt/tmp/100MB.31.raw: Input/output error
md5sum: /mnt/tmp/100MB.32.raw: Input/output error
md5sum: /mnt/tmp/100MB.33.raw: Input/output error
md5sum: /mnt/tmp/100MB.34.raw: Input/output error
md5sum: /mnt/tmp/100MB.35.raw: Input/output error
md5sum: /mnt/tmp/100MB.36.raw: Input/output error
md5sum: /mnt/tmp/100MB.37.raw: Input/output error
md5sum: /mnt/tmp/100MB.38.raw: Input/output error
md5sum: /mnt/tmp/100MB.39.raw: Input/output error
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.4.raw
md5sum: /mnt/tmp/100MB.40.raw: Input/output error
md5sum: /mnt/tmp/100MB.41.raw: Input/output error
md5sum: /mnt/tmp/100MB.42.raw: Input/output error
md5sum: /mnt/tmp/100MB.43.raw: Input/output error
md5sum: /mnt/tmp/100MB.44.raw: Input/output error
md5sum: /mnt/tmp/100MB.45.raw: Input/output error
md5sum: /mnt/tmp/100MB.46.raw: Input/output error
md5sum: /mnt/tmp/100MB.47.raw: Input/output error
md5sum: /mnt/tmp/100MB.48.raw: Input/output error
md5sum: /mnt/tmp/100MB.49.raw: Input/output error
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.5.raw
md5sum: /mnt/tmp/100MB.50.raw: Input/output error
md5sum: /mnt/tmp/100MB.51.raw: Input/output error
d41d8cd98f00b204e9800998ecf8427e /mnt/tmp/100MB.52.raw
d41d8cd98f00b204e9800998ecf8427e /mnt/tmp/100MB.53.raw
d41d8cd98f00b204e9800998ecf8427e /mnt/tmp/100MB.54.raw
d41d8cd98f00b204e9800998ecf8427e /mnt/tmp/100MB.55.raw
d41d8cd98f00b204e9800998ecf8427e /mnt/tmp/100MB.56.raw
d41d8cd98f00b204e9800998ecf8427e /mnt/tmp/100MB.57.raw
d41d8cd98f00b204e9800998ecf8427e /mnt/tmp/100MB.58.raw
d41d8cd98f00b204e9800998ecf8427e /mnt/tmp/100MB.59.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.6.raw
d41d8cd98f00b204e9800998ecf8427e /mnt/tmp/100MB.60.raw
d41d8cd98f00b204e9800998ecf8427e /mnt/tmp/100MB.61.raw
d41d8cd98f00b204e9800998ecf8427e /mnt/tmp/100MB.62.raw
d41d8cd98f00b204e9800998ecf8427e /mnt/tmp/100MB.63.raw
d41d8cd98f00b204e9800998ecf8427e /mnt/tmp/100MB.64.raw
d41d8cd98f00b204e9800998ecf8427e /mnt/tmp/100MB.65.raw
d41d8cd98f00b204e9800998ecf8427e /mnt/tmp/100MB.66.raw
d41d8cd98f00b204e9800998ecf8427e /mnt/tmp/100MB.67.raw
d41d8cd98f00b204e9800998ecf8427e /mnt/tmp/100MB.68.raw
d41d8cd98f00b204e9800998ecf8427e /mnt/tmp/100MB.69.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.7.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.8.raw
1403cd0ffe5f93c99d8efb75a1a69ef5 /mnt/tmp/100MB.9.raw

# again unmounting and running e2fsck reports many FS errors.
# I've also run the badblocks tests on another machine, same Slackware
# distro, different H/W, same results.


System details:
Slackware Linux 11.0
Linux mklab 2.6.20 #7 Wed Sep 5 03:23:16 BST 2007 i686 athlon-4 i386 GNU/Linux
E2fsprogs version 1.39

Ps. The email address in the header is just a spam-trap.
--
Tom Crane, Dept. Physics, Royal Holloway, University of London, Egham Hill,
Egham, Surrey, TW20 0EX, England.
Email: T.Crane at rhul dot ac dot uk
Fax: +44 (0) 1784 472794

On Wed, 25 Jun 2008 04:04:48 +0000, UHAP023 wrote:

> Dear All,
> I have an 8GB USB memory stick which I believe is faulty. I know
> there are duff USB sticks out there on the market. The vendor assures
> me that all items are checked before dispatch and so I would like to
> demonstrate/verify the problem for him.
>
> The device identifies its capacity as 8GB and will format OK (under both
> WinXP PRO SP2 / FAT32 and Linux Ext2 & FAT32). The symptoms are if less
> than ~2GB is used the data remains valid. If more than ~2GB is used
> corrupt files result. Running badblocks in default write mode (fills
> the whole device & then verifies, with in turn; 0xaa, 0x55, 0xff, 0x00)
> shows no errors but in random byte mode, beyond block 2059776 (ie.
> approx. 2GB) is flagged as bad.
>
> Below is the set of tests I've used. Is there anything I've overlooked?
>
> Thanks
> Tom Crane.
>

I believe you your vendor should also, tell them the same thing that you
told us. Don't mention Linux when you talk to them, just say that you ran
a disk diagnostic. Who did you buy the FLASH drive from?

on Wednesday 25 June 2008 14:04
in the Usenet newsgroup comp.os.linux.hardware
UHAP023@alpha1.rhbnc.ac.uk wrote:

> Dear All,
> I have an 8GB USB memory stick which I believe is faulty. I know
> there are duff USB sticks out there on the market. The vendor assures
> me that all items are checked before dispatch and so I would like to
> demonstrate/verify the problem for him.
>
> The device identifies its capacity as 8GB and will format OK (under
> both WinXP PRO SP2 / FAT32 and Linux Ext2 & FAT32). The symptoms are
> if less than ~2GB is used the data remains valid. If more than ~2GB
> is used corrupt files result. Running badblocks in default write mode
> (fills the whole device & then verifies, with in turn; 0xaa, 0x55,
> 0xff, 0x00) shows no errors but in random byte mode, beyond block
> 2059776 (ie. approx. 2GB) is flagged as bad.
>
> Below is the set of tests I've used. Is there anything I've overlooked?
[snip]

32 bit limit?


--
sig goes here...
Peter D.

On Wed, 25 Jun 2008 22:38:54 +1000, Peter D. wrote:

> on Wednesday 25 June 2008 14:04
> in the Usenet newsgroup comp.os.linux.hardware
> UHAP023@alpha1.rhbnc.ac.uk wrote:
>
>> Dear All,
>> I have an 8GB USB memory stick which I believe is faulty. I know
>> there are duff USB sticks out there on the market. The vendor assures
>> me that all items are checked before dispatch and so I would like to
>> demonstrate/verify the problem for him.
>>
>> The device identifies its capacity as 8GB and will format OK (under
>> both WinXP PRO SP2 / FAT32 and Linux Ext2 & FAT32). The symptoms are if
>> less than ~2GB is used the data remains valid. If more than ~2GB is
>> used corrupt files result. Running badblocks in default write mode
>> (fills the whole device & then verifies, with in turn; 0xaa, 0x55,
>> 0xff, 0x00) shows no errors but in random byte mode, beyond block
>> 2059776 (ie. approx. 2GB) is flagged as bad.
>>
>> Below is the set of tests I've used. Is there anything I've
>> overlooked?
> [snip]
>
> 32 bit limit?

First generation SD card readers were limited to 2G, the SDHC standard
raised that. I don't know if there was ever a limit for USB FLASH drives,
I doubt it because the controller is part of the drive. Also the fact
that the OP's systems see the drive as 8G would indicate that there isn't
any hardware limit.

General Schvantzkopf <schvantzkopf@yahoo.com> wrote:
: On Wed, 25 Jun 2008 22:38:54 +1000, Peter D. wrote:

: > on Wednesday 25 June 2008 14:04
: > in the Usenet newsgroup comp.os.linux.hardware
: > UHAP023@alpha1.rhbnc.ac.uk wrote:
: >
: >> Dear All,
: >> I have an 8GB USB memory stick which I believe is faulty. I know
: >> there are duff USB sticks out there on the market. The vendor assures
: >> me that all items are checked before dispatch and so I would like to
: >> demonstrate/verify the problem for him.
: >>
: >> The device identifies its capacity as 8GB and will format OK (under
: >> both WinXP PRO SP2 / FAT32 and Linux Ext2 & FAT32). The symptoms are if
: >> less than ~2GB is used the data remains valid. If more than ~2GB is
: >> used corrupt files result. Running badblocks in default write mode
: >> (fills the whole device & then verifies, with in turn; 0xaa, 0x55,
: >> 0xff, 0x00) shows no errors but in random byte mode, beyond block
: >> 2059776 (ie. approx. 2GB) is flagged as bad.
: >>
: >> Below is the set of tests I've used. Is there anything I've
: >> overlooked?
: > [snip]
: >
: > 32 bit limit?

: First generation SD card readers were limited to 2G, the SDHC standard
: raised that. I don't know if there was ever a limit for USB FLASH drives,
: I doubt it because the controller is part of the drive. Also the fact
: that the OP's systems see the drive as 8G would indicate that there isn't
: any hardware limit.

Agreed. Also my first bad block seems rather far from the 2GB limit;

tmp$ echo $[2**31] ! 2GB limit as bytes
2147483648
tmp$ echo $[1024*2059776] ! My first bad block as bytes
2109210624
tmp$ echo $[(2147483648-2109210624)/(1024*1024)] ! difference as MB.
36

Could anybody with a known good 8GB USB stick and similar kernel
reproduce/refute my results?

Cheers
Tom Crane.

Ps. The email address in the header is just a spam-trap.
--
Tom Crane, Dept. Physics, Royal Holloway, University of London, Egham Hill,
Egham, Surrey, TW20 0EX, England.
Email: T.Crane at rhul dot ac dot uk
Fax: +44 (0) 1784 472794

In article <g3tvmo$tf7$1@mklab.ph.rhul.ac.uk>,
<UHAP023@alpha1.rhbnc.ac.uk> wrote:
> General Schvantzkopf <schvantzkopf@yahoo.com> wrote:
> : On Wed, 25 Jun 2008 22:38:54 +1000, Peter D. wrote:
>
> : > on Wednesday 25 June 2008 14:04
> : > in the Usenet newsgroup comp.os.linux.hardware
> : > UHAP023@alpha1.rhbnc.ac.uk wrote:
> : >
> : >> in random byte mode, beyond block
> : >> 2059776 (ie. approx. 2GB) is flagged as bad.
> : >>
> : >> Below is the set of tests I've used. Is there anything I've
> : >> overlooked?
> : > [snip]
> : >
> : > 32 bit limit?
>
> : First generation SD card readers were limited to 2G, the SDHC standard
> : raised that. I don't know if there was ever a limit for USB FLASH drives,
> : I doubt it because the controller is part of the drive. Also the fact
> : that the OP's systems see the drive as 8G would indicate that there isn't
> : any hardware limit.
>
> Agreed. Also my first bad block seems rather far from the 2GB limit;
>
> tmp$ echo $[2**31] ! 2GB limit as bytes
> 2147483648
> tmp$ echo $[1024*2059776] ! My first bad block as bytes
> 2109210624
> tmp$ echo $[(2147483648-2109210624)/(1024*1024)] ! difference as MB.
> 36

So that's 36 MB into a what, 100 MB file? Sounds like a failure criterion
to me. Can you try something like

0/:
file_00
file_01
...
file_09
1/:
file_10
file_11
...
file_19
....
7/:
file_70
file_71
...
file_79

Why are you making a bunch of identical big files anyway? Just to fill
up the stick?

--
A well-lovd and corrctly traind domstc cnine is gnrlly slobbry, excitbl,
noisy, scatologically obsessed, xenophobic, pathetically unjudgmental,
embrrssngly uninhbtd, unreasnngly dvtd, hrtbrkngly dpndnt and wretchedly
craven. All othr knds of dog cmpre unfvrbly wth ths picture. - PB, AFCA

UHAP023@alpha1.rhbnc.ac.uk schrob:

> Dear All,
> I have an 8GB USB memory stick which I believe is faulty. I know
> there are duff USB sticks out there on the market. The vendor assures
> me that all items are checked before dispatch and so I would like to
> demonstrate/verify the problem for him.
>
> The device identifies its capacity as 8GB and will format OK (under
> both WinXP PRO SP2 / FAT32 and Linux Ext2 & FAT32). The symptoms are
> if less than ~2GB is used the data remains valid. If more than ~2GB
> is used corrupt files result. Running badblocks in default write mode
> (fills the whole device & then verifies, with in turn; 0xaa, 0x55,
> 0xff, 0x00) shows no errors but in random byte mode, beyond block
> 2059776 (ie. approx. 2GB) is flagged as bad.
>
> Below is the set of tests I've used. Is there anything I've overlooked?

A year ago vendors deliberately mislabelled their devices with incorrect
capacities. Someone from heise wrote a test tool für this case:
http://www.wintotal.de/Software/?id=4379
I don't know if it tells you more than you already know (because I haven't
used it yet), but you can still have a look.
--
Gruß | Greetings | Qapla'
What do you call a dead bee? - A was.

Hactar <ebenZEROONE@verizon.net> wrote:
: In article <g3tvmo$tf7$1@mklab.ph.rhul.ac.uk>,
: <UHAP023@alpha1.rhbnc.ac.uk> wrote:
: > General Schvantzkopf <schvantzkopf@yahoo.com> wrote:
: > : On Wed, 25 Jun 2008 22:38:54 +1000, Peter D. wrote:
: >
: > : > on Wednesday 25 June 2008 14:04
: > : > in the Usenet newsgroup comp.os.linux.hardware
: > : > UHAP023@alpha1.rhbnc.ac.uk wrote:
: > : >
: > : >> in random byte mode, beyond block
: > : >> 2059776 (ie. approx. 2GB) is flagged as bad.
: > : >>
: > : >> Below is the set of tests I've used. Is there anything I've
: > : >> overlooked?
: > : > [snip]
: > : >
: > : > 32 bit limit?
: >
: > : First generation SD card readers were limited to 2G, the SDHC standard
: > : raised that. I don't know if there was ever a limit for USB FLASH drives,
: > : I doubt it because the controller is part of the drive. Also the fact
: > : that the OP's systems see the drive as 8G would indicate that there isn't
: > : any hardware limit.
: >
: > Agreed. Also my first bad block seems rather far from the 2GB limit;
: >
: > tmp$ echo $[2**31] ! 2GB limit as bytes
: > 2147483648
: > tmp$ echo $[1024*2059776] ! My first bad block as bytes
: > 2109210624
: > tmp$ echo $[(2147483648-2109210624)/(1024*1024)] ! difference as MB.
: > 36

: So that's 36 MB into a what, 100 MB file? Sounds like a failure criterion
: to me. Can you try something like

: 0/:
: file_00
: file_01
: ...
: file_09
: 1/:
: file_10
: file_11
: ...
: file_19
: ...
: 7/:
: file_70
: file_71
: ...
: file_79

That is pretty much what I was doing, except I had everything in the root
directory -- the total number of files was small after-all.

: Why are you making a bunch of identical big files anyway? Just to fill
: up the stick?

Exactly. It was just an easy way to check all its memory by checking
each file for integrity since I already had its md5 checksum. Any
corrupt space on the device then shows up easily.

Regards
Tom.

Ps. The email address in the header is just a spam-trap.
--
Tom Crane, Dept. Physics, Royal Holloway, University of London, Egham Hill,
Egham, Surrey, TW20 0EX, England.
Email: T.Crane at rhul dot ac dot uk
Fax: +44 (0) 1784 472794

Frank Steinmetzger <Warp_7@gmx.de> wrote:
: UHAP023@alpha1.rhbnc.ac.uk schrob:

: > Dear All,
: > I have an 8GB USB memory stick which I believe is faulty. I know
[cut]
: > Below is the set of tests I've used. Is there anything I've overlooked?

: A year ago vendors deliberately mislabelled their devices with incorrect
: capacities. Someone from heise wrote a test tool f?r this case:
: http://www.wintotal.de/Software/?id=4379
: I don't know if it tells you more than you already know (because I haven't
: used it yet), but you can still have a look.

Many thanks for that tip. I've tested the memory stick with it on a
couple of different machines. Both give the same diagnostic as
follows;

The media is likely to be defective.
1.9 GByte OK (4087424 sectors)
5.8 GByte DATA LOST (12274048 sectors)
Details:5.8 GByte overwritten (12274048 sectors)
0 KByte slightly changed (< 8 bit/sector, 0 sectors)
0 KByte corrupted (0 sectors)
2 KByte aliased memory (4 sectors)
First error at offset: 0x000000007cbd0000
Expected: 0x000000007cbd0000
Found: 0x000000007cbcf800
H2testw version 1.3
Writing speed: 6.33 MByte/s
Reading speed: 12.9 MByte/s
H2testw v1.4

I don't think there can be any doubt now that the USB stick is faulty.

Cheers
Tom.

Ps. The email address in the header is just a spam-trap.
--
Tom Crane, Dept. Physics, Royal Holloway, University of London, Egham Hill,
Egham, Surrey, TW20 0EX, England.
Email: T.Crane at rhul dot ac dot uk
Fax: +44 (0) 1784 472794

In article <g43ii4$udg$1@mklab.ph.rhul.ac.uk>,
<UHAP023@alpha1.rhbnc.ac.uk> wrote:
> Hactar <ebenZEROONE@verizon.net> wrote:
> : Can you try something like
>
> : 0/:
> : file_00
> : file_01
> : ...
> : file_09
> : 1/:
> : file_10
> : file_11
> : ...
> : file_19
> : ...
> : 7/:
> : file_70
> : file_71
> : ...
> : file_79
>
> That is pretty much what I was doing, except I had everything in the root
> directory -- the total number of files was small after-all.
>
> : Why are you making a bunch of identical big files anyway? Just to fill
> : up the stick?
>
> Exactly. It was just an easy way to check all its memory by checking
> each file for integrity since I already had its md5 checksum. Any
> corrupt space on the device then shows up easily.

Instead of 80 100-MB files, try 40 200-MB files and 160 50-MB files.
See whether it fails in about the same place.

--
-eben QebWenE01R@vTerYizUonI.nOetP royalty.mine.nu:81
> A: It's annoying as hell
> Q: Why do most people hate top-posting? -- Lots42 The Library Avenger
http://www.fscked.co.uk/writing/top-posting-cuss.html