Diagnosing a faulty 8GB USB drive - Hardware

This is a discussion on Diagnosing a faulty 8GB USB drive - Hardware ; 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 ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Diagnosing a faulty 8GB USB drive

  1. Diagnosing a faulty 8GB USB drive

    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


  2. Re: Diagnosing a faulty 8GB USB drive

    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?

  3. Re: Diagnosing a faulty 8GB USB drive

    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.

  4. Re: Diagnosing a faulty 8GB USB drive

    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.


  5. Re: Diagnosing a faulty 8GB USB drive

    General Schvantzkopf 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


  6. Re: Diagnosing a faulty 8GB USB drive

    In article ,
    wrote:
    > General Schvantzkopf 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

  7. Re: Diagnosing a faulty 8GB USB drive

    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.


  8. Re: Diagnosing a faulty 8GB USB drive

    Hactar wrote:
    : In article ,
    : wrote:
    : > General Schvantzkopf 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


  9. Re: Diagnosing a faulty 8GB USB drive

    Frank Steinmetzger 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


  10. Re: Diagnosing a faulty 8GB USB drive

    In article ,
    wrote:
    > Hactar 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

  11. Re: Diagnosing a faulty 8GB USB drive

    On Wed, 25 Jun 2008 04:04:48 +0000 (UTC) UHAP023@alpha1.rhbnc.ac.uk wrote:

    | 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?

    This would give me some bit of more accurate info:

    fdisk -lu /dev/sda

    The "u" specifies to give partitions in sectors instead of cylinders.

    Also, what do you get from doing this command (which would destroy all the
    contents on the device, including the partition table):

    dd if=/dev/urandom of=/dev/sda oflag=direct bs=4096 count=2049467

    You can restore the partition table by writing zeroes and repartitioning
    using the information from doing a partition list:

    dd if=/dev/zero of=/dev/sda oflag=direct bs=4096 count=16
    fdisk /dev/sda



    | 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...

    I'd be curious just what specific errors happened. Bit inversions?
    Copy between blocks? Shifting? Apparently whatever error is
    something not affected by the non-random pattern.

    What I'd do in this case is create a regular disk file with exactly the same
    number of blocks as the USB key (so you need 8GB free space on disk somewhere)
    and compare the data:

    dd if=/dev/urandom of=random.bits bs=4096 count=2049467
    dd if=random.bits of=/dev/sda oflag=direct bs=4096 count=2049467
    cmp -l random.bits /dev/sda | tree random.errs

    I just ran the badblocks test on a 2GB CF card (sdc), a 2GB SD card (sdd), and
    a 4GB USB key (sde), and got no errors. So you are definitely getting something
    I have not gotten. So there's no way someone can say that the output you see is
    in any way a normal output. OTOH, these are not perfect random patterns they
    use, as they do repeat and could fail to detect certain leakage issues.

    ================================================== ==============
    root@faraday:/root 1# time badblocks -v -w -t random /dev/sdc
    Checking for bad blocks in read-write mode
    From block 0 to 2000880
    Testing with random pattern: done
    Reading and comparing: done
    Pass completed, 0 bad blocks found.
    [[ 4m32s real 272.337 - user 4.891 - sys 1.034 - 2.17% ]]
    root@faraday:/root 2# time badblocks -v -w -t random /dev/sdd
    Checking for bad blocks in read-write mode
    From block 0 to 1985024
    Testing with random pattern: done
    Reading and comparing: done
    Pass completed, 0 bad blocks found.
    [[ 9m19s real 559.866 - user 4.865 - sys 0.814 - 1.01% ]]
    root@faraday:/root 3# time badblocks -v -w -t random /dev/sde
    Checking for bad blocks in read-write mode
    From block 0 to 4007752
    Testing with random pattern: done
    Reading and comparing: done
    Pass completed, 0 bad blocks found.
    [[ 12m21s real 741.825 - user 9.872 - sys 1.593 - 1.54% ]]
    root@faraday:/root 4# od -x < /dev/sdc | head
    0000000 7022 f72b c339 2309 e054 4770 c955 c9b8
    0000020 1412 d9e8 159d 4a98 d3e8 2697 6dff 21a4
    0000040 d0dd 1618 2193 e739 a901 562e e673 851f
    0000060 07fa 975e f61d 05e1 78c9 c82c d0e6 c3e9
    0000100 01a0 33da 1322 241a 48bd 307a 9a2e 28b5
    0000120 13a1 bebf a009 d3c4 f019 ff9b 85c0 61c2
    0000140 9c86 a994 afb0 6dcd 47f7 269d 52e1 834e
    0000160 0e65 6e41 05ae c741 ddf5 b6c6 8962 e817
    0000200 ab25 d591 5e5a 5242 dfa6 8778 c631 960a
    0000220 4cd4 8305 4651 474a 1123 85fd 149a bf6e
    root@faraday:/root 5# od -x < /dev/sdd | head
    0000000 20a8 7780 6916 5043 dffd 0473 c242 7177
    0000020 79fc f9f5 141d 9790 3822 0392 5e00 a9bc
    0000040 3c7e 9520 64a5 a2e5 5943 86a7 1e1b 17f7
    0000060 ec98 b510 a100 224c ded9 da26 e23c ba83
    0000100 a31e c34f 3507 4b66 0d8e a9d1 c82b c3c0
    0000120 d0b5 b578 c471 4bd8 fea2 de25 a8e0 fe99
    0000140 e84b 53c1 271d ab9e 6f34 6054 1437 ec23
    0000160 9ce5 56a2 7a60 03a1 c678 58e1 7a6e ba56
    0000200 1763 800d ab3f 732c 801a 51d3 f795 7a3e
    0000220 e093 f3d0 725a d2f6 d838 a72a 8052 b561
    root@faraday:/root 6# od -x < /dev/sde | head
    0000000 9427 ab08 dab1 5033 d214 274d 8908 9515
    0000020 64c3 64df 8843 0b56 d904 706c 0ee9 10a7
    0000040 afa3 54bb ee8a 9ea5 f2c1 c9c5 db7c 3f5e
    0000060 3e3f 82a3 f9c6 ca8e fad3 bc3b e209 accc
    0000100 8792 1c00 a576 37ba 8098 1400 5e5b 9a53
    0000120 f69c 621c aaf0 c32d 68a5 ae7f 4b4a dc5a
    0000140 5ad2 48f8 b300 987f 7f33 8eac ffde 7a28
    0000160 44f5 e5dd 0aef 94a8 2772 bc42 9c72 4599
    0000200 91f6 f68d 0d44 778e 3a8c 6a05 2d39 2fe5
    0000220 c272 6114 bdcc 3ef5 37e4 57fa 93d3 c99c
    root@faraday:/root 7# od -x < /dev/sdc | fgrep '7022 f72b c339 2309 e054 4770 c955 c9b8' | head
    0000000 7022 f72b c339 2309 e054 4770 c955 c9b8
    0200000 7022 f72b c339 2309 e054 4770 c955 c9b8
    0400000 7022 f72b c339 2309 e054 4770 c955 c9b8
    0600000 7022 f72b c339 2309 e054 4770 c955 c9b8
    1000000 7022 f72b c339 2309 e054 4770 c955 c9b8
    1200000 7022 f72b c339 2309 e054 4770 c955 c9b8
    1400000 7022 f72b c339 2309 e054 4770 c955 c9b8
    1600000 7022 f72b c339 2309 e054 4770 c955 c9b8
    2000000 7022 f72b c339 2309 e054 4770 c955 c9b8
    2200000 7022 f72b c339 2309 e054 4770 c955 c9b8
    root@faraday:/root 8# od -x < /dev/sdd | fgrep '20a8 7780 6916 5043 dffd 0473 c242 7177' | head
    0000000 20a8 7780 6916 5043 dffd 0473 c242 7177
    0200000 20a8 7780 6916 5043 dffd 0473 c242 7177
    0400000 20a8 7780 6916 5043 dffd 0473 c242 7177
    0600000 20a8 7780 6916 5043 dffd 0473 c242 7177
    1000000 20a8 7780 6916 5043 dffd 0473 c242 7177
    1200000 20a8 7780 6916 5043 dffd 0473 c242 7177
    1400000 20a8 7780 6916 5043 dffd 0473 c242 7177
    1600000 20a8 7780 6916 5043 dffd 0473 c242 7177
    2000000 20a8 7780 6916 5043 dffd 0473 c242 7177
    2200000 20a8 7780 6916 5043 dffd 0473 c242 7177
    root@faraday:/root 9# od -x < /dev/sde | fgrep '9427 ab08 dab1 5033 d214 274d 8908 9515' | head
    0000000 9427 ab08 dab1 5033 d214 274d 8908 9515
    0200000 9427 ab08 dab1 5033 d214 274d 8908 9515
    0400000 9427 ab08 dab1 5033 d214 274d 8908 9515
    0600000 9427 ab08 dab1 5033 d214 274d 8908 9515
    1000000 9427 ab08 dab1 5033 d214 274d 8908 9515
    1200000 9427 ab08 dab1 5033 d214 274d 8908 9515
    1400000 9427 ab08 dab1 5033 d214 274d 8908 9515
    1600000 9427 ab08 dab1 5033 d214 274d 8908 9515
    2000000 9427 ab08 dab1 5033 d214 274d 8908 9515
    2200000 9427 ab08 dab1 5033 d214 274d 8908 9515
    root@faraday:/root 10#
    ================================================== ==============

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  12. Re: Diagnosing a faulty 8GB USB drive

    phil-news-nospam@ipal.net wrote:
    : On Wed, 25 Jun 2008 04:04:48 +0000 (UTC) UHAP023@alpha1.rhbnc.ac.uk wrote:

    : | 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?

    Unfortunately I've returned the USB stick to the vendor who offered a
    full refund.

    : This would give me some bit of more accurate info:

    : fdisk -lu /dev/sda

    : The "u" specifies to give partitions in sectors instead of cylinders.

    Sure but I would be surprised if the partition table were bad, firstly
    because Linux fdisk created and subsequently reported it as OK and
    secondly because the first corrupt sector reported by badblocks was
    consistently far above the first 512 bytes (~2GB).

    : I'd be curious just what specific errors happened. Bit inversions?
    : Copy between blocks? Shifting? Apparently whatever error is
    : something not affected by the non-random pattern.

    Yes, this would have been interesting to know. However 0xaa, 0x55,
    0xff & 0x00 is not a bad test suite since it checks all bits with and
    without different bit neighbours. The other possibility as you say is
    that adjacent (or even other non-adjacent) (byte) locations have a
    corrupting effect. I copied some MP3 files to the device and those
    lying beyond the first ~2GB were, IIRC quite corrupt. Dumping some of
    the files I used shows they comprise a short header with title/track
    etc. information followed by a block of 0x00 bytes and then the
    (naturally high entropy) coded audio data. IIRC those read back files
    beyond ~2GB were unrecognisable -- eg. no blocks of identical data as
    one would get with bit-inverted blocks of 0x00. Then again this was
    being done under an FS which certainly had acquired corruptions...

    : I just ran the badblocks test on a 2GB CF card (sdc), a 2GB SD card (sdd), and
    : a 4GB USB key (sde), and got no errors. So you are definitely getting something
    : I have not gotten. So there's no way someone can say that the output you see is
    : in any way a normal output. OTOH, these are not perfect random patterns they
    : use, as they do repeat and could fail to detect certain leakage issues.

    Thanks for running these tests. In particular your successful
    /dev/sde test indicates 2GB size limits were probably not the problem
    as was suggested might be the case further up this thread.

    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


  13. Re: Diagnosing a faulty 8GB USB drive

    On Fri, 11 Jul 2008 15:45:15 +0000 (UTC) UHAP023@alpha1.rhbnc.ac.uk wrote:

    | Unfortunately I've returned the USB stick to the vendor who offered a
    | full refund.

    Well at least you get to start over with a new one, if you elect to buy
    another.


    | Yes, this would have been interesting to know. However 0xaa, 0x55,
    | 0xff & 0x00 is not a bad test suite since it checks all bits with and
    | without different bit neighbours. The other possibility as you say is
    | that adjacent (or even other non-adjacent) (byte) locations have a
    | corrupting effect. I copied some MP3 files to the device and those
    | lying beyond the first ~2GB were, IIRC quite corrupt. Dumping some of
    | the files I used shows they comprise a short header with title/track
    | etc. information followed by a block of 0x00 bytes and then the
    | (naturally high entropy) coded audio data. IIRC those read back files
    | beyond ~2GB were unrecognisable -- eg. no blocks of identical data as
    | one would get with bit-inverted blocks of 0x00. Then again this was
    | being done under an FS which certainly had acquired corruptions...

    I've found that pattern sequence has failed to detect RAM errors in the
    past. There are a lot of ways to leak between bits and this pattern
    could line up with one leak and always leak the same bit and hence not
    be seen.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

+ Reply to Thread