Hi,
I can write to just about the entire USB stick, with no errors:
atom:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 5.8G 1.5G 4.3G 26% /
tmpfs 2.0G 0 2.0G 0% /lib/init/rw
udev 10M 140K 9.9M 2% /dev
tmpfs 2.0G 0 2.0G 0% /dev/shm
atom:~# cd /
atom:/# ls
bin cdrom etc lib media nfs proc sbin srv tmp var
boot dev home lib64 mnt opt root selinux sys usr
atom:/# dd if=/dev/zero of=bigfile bs=1M count=4000
4000+0 records in
4000+0 records out
4194304000 bytes (4.2 GB) copied, 135.536 s, 30.9 MB/s
atom:/# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 5.8G 5.4G 350M 95% /
tmpfs 2.0G 0 2.0G 0% /lib/init/rw
udev 10M 140K 9.9M 2% /dev
tmpfs 2.0G 0 2.0G 0% /dev/shm
atom:/# rm bigfile
However, after some amount of time, the errors occur below, is this USB
stick failing? Since it has no SMART, is there any other way to verify
the 'health' of a USB stick?
Mar 18 07:55:12 atom [ 10.034310] e1000e 0000:03:00.0: eth1: 10/100 speed: disabling TSO
[ .. no errors .. ]
Mar 18 08:32:44 atom [ 2261.883848] usb 1-1: USB disconnect, address 2
Mar 18 08:32:44 atom [ 2261.884465] Buffer I/O error on device sda2, logical block 1317256
Mar 18 08:32:44 atom [ 2261.884525] lost page write due to I/O error on sda2
Mar 18 08:32:44 atom [ 2261.884713] Buffer I/O error on device sda2, logical block 1307821
Mar 18 08:32:44 atom [ 2261.884764] lost page write due to I/O error on sda2
Mar 18 08:33:06 atom [ 2283.744165] sd 6:0:0:0: Device offlined - not ready after error recovery
Mar 18 08:33:06 atom [ 2283.744264] sd 6:0:0:0: [sda] Unhandled error code
Mar 18 08:33:06 atom [ 2283.744298] sd 6:0:0:0: [sda]
Mar 18 08:33:06 atom Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Mar 18 08:33:06 atom [ 2283.744356] sd 6:0:0:0: [sda] CDB:
Mar 18 08:33:06 atom Write(10)
Mar 18 08:33:06 atom :
Mar 18 08:33:06 atom 2a
Mar 18 08:33:06 atom 00
Mar 18 08:33:06 atom 00
Mar 18 08:33:06 atom 99
Mar 18 08:33:06 atom 0f
Mar 18 08:33:06 atom 7e
Mar 18 08:33:06 atom 00
Mar 18 08:33:06 atom 00
Mar 18 08:33:06 atom 02
Mar 18 08:33:06 atom 00
Mar 18 08:33:06 atom
Mar 18 08:33:06 atom [ 2283.744450] end_request: I/O error, dev sda, sector 10030974
Mar 18 08:33:06 atom [ 2283.744544] I/O error in filesystem ("sda2") meta-data dev sda2 block 0x5c05c5 ("xlog_iodone") error 5 buf count 1024
Mar 18 08:33:06 atom
Mar 18 08:33:06 atom [ 2283.744591] xfs_force_shutdown(sda2,0x2) called from line 893 of file fs/xfs/xfs_log.c. Return address = 0xffffffff811c9834
Mar 18 08:33:06 atom
Mar 18 08:33:06 atom [ 2283.744669] Filesystem sda2: Log I/O Error Detected. Shutting down filesystem: sda2
Mar 18 08:33:06 atom
Mar 18 08:33:06 atom [ 2283.744732] Please umount the filesystem, and rectify the problem(s)
Mar 18 08:33:06 atom
Mar 18 08:33:06 atom [ 2283.744779] Buffer I/O error on device sda2, logical block 1318284
Mar 18 08:33:06 atom [ 2283.744831] lost page write due to I/O error on sda2
Mar 18 08:33:06 atom [ 2283.745659] Filesystem sda2: xfs_log_force: error 5 returned.
Mar 18 08:33:06 atom
Mar 18 08:33:06 atom [ 2283.746109] Filesystem sda2: xfs_log_force: error 5 returned.
Mar 18 08:33:06 atom
Mar 18 08:33:06 atom [ 2283.746168] xfs_force_shutdown(sda2,0x1) called from line 1111 of file fs/xfs/linux-2.6/xfs_buf.c. Return address = 0xffffffff811e1e1c
Mar 18 08:33:06 atom
Mar 18 08:33:06 atom [ 2283.963059] usb 1-1: new high speed USB device using ehci_hcd and address 4
Mar 18 08:33:06 atom [ 2284.080647] usb 1-1: New USB device found, idVendor=0325, idProduct=ac02
Mar 18 08:33:06 atom [ 2284.080707] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 18 08:33:06 atom [ 2284.080752] usb 1-1: Product: R2_TURBO
Mar 18 08:33:06 atom [ 2284.080794] usb 1-1: Manufacturer: OCZ Technology
Mar 18 08:33:06 atom [ 2284.080831] usb 1-1: SerialNumber: (removed)
Mar 18 08:33:06 atom [ 2284.082082] scsi7 : usb-storage 1-1:1.0
Mar 18 08:33:07 atom [ 2285.083417] scsi 7:0:0:0: Direct-Access OCZ R2_TURBO 1100 PQ: 0 ANSI: 0 CCS
Mar 18 08:33:07 atom [ 2285.085539] sd 7:0:0:0: [sdb] 16056320 512-byte logical blocks: (8.22 GB/7.65 GiB)
Mar 18 08:33:07 atom [ 2285.086520] sd 7:0:0:0: [sdb] Write Protect is off
Mar 18 08:33:07 atom [ 2285.089383] sd 7:0:0:0: [sdb] No Caching mode page present
Mar 18 08:33:07 atom [ 2285.089435] sd 7:0:0:0: [sdb] Assuming drive cache: write through
Mar 18 08:33:07 atom [ 2285.094025] sd 7:0:0:0: [sdb] No Caching mode page present
Mar 18 08:33:07 atom [ 2285.094071] sd 7:0:0:0: [sdb] Assuming drive cache: write through
Mar 18 08:33:07 atom [ 2285.094888] sdb: sdb1 sdb2
Mar 18 08:33:07 atom [ 2285.097544] sd 7:0:0:0: [sdb] No Caching mode page present
Mar 18 08:33:07 atom [ 2285.097602] sd 7:0:0:0: [sdb] Assuming drive cache: write through
Mar 18 08:33:07 atom [ 2285.097647] sd 7:0:0:0: [sdb] Attached SCSI removable disk
Mar 18 08:33:36 atom [ 2313.744037] Filesystem sda2: xfs_log_force: error 5 returned.
Mar 18 08:34:06 atom
Mar 18 08:34:06 atom [ 2343.745039] Filesystem sda2: xfs_log_force: error 5 returned.
Mar 18 08:34:36 atom
Mar 18 08:34:36 atom [ 2373.745039] Filesystem sda2: xfs_log_force: error 5 returned.
Mar 18 08:35:06 atom
On Mar 18, 2011, at 10:08 AM, Justin Piszcz wrote:
> Hi,
>
> I can write to just about the entire USB stick, with no errors:
>
> atom:~# df -h
> Filesystem Size Used Avail Use% Mounted on
> /dev/sda2 5.8G 1.5G 4.3G 26% /
> tmpfs 2.0G 0 2.0G 0% /lib/init/rw
> udev 10M 140K 9.9M 2% /dev
> tmpfs 2.0G 0 2.0G 0% /dev/shm
> atom:~# cd /
> atom:/# ls
> bin cdrom etc lib media nfs proc sbin srv tmp var
> boot dev home lib64 mnt opt root selinux sys usr
> atom:/# dd if=/dev/zero of=bigfile bs=1M count=4000
> 4000+0 records in
> 4000+0 records out
> 4194304000 bytes (4.2 GB) copied, 135.536 s, 30.9 MB/s
> atom:/# df -h
> Filesystem Size Used Avail Use% Mounted on
> /dev/sda2 5.8G 5.4G 350M 95% /
> tmpfs 2.0G 0 2.0G 0% /lib/init/rw
> udev 10M 140K 9.9M 2% /dev
> tmpfs 2.0G 0 2.0G 0% /dev/shm
> atom:/# rm bigfile
>
> However, after some amount of time, the errors occur below, is this USB
> stick failing? Since it has no SMART, is there any other way to verify
> the 'health' of a USB stick?
What prompted you to go with XFS over, say, ext2? The journal will generally cause quite a bit more writes onto your USB device. I use ext2 on my CF card in my NAS for that reason (the spinning media is on XFS of course). I know that's not an answer to your problem but thought I would add it as a suggestion :)
Tim
On Fri, 18 Mar 2011, Justin Piszcz wrote:
> Hi,
>
> I can write to just about the entire USB stick, with no errors:
>
> atom:~# df -h
> Filesystem Size Used Avail Use% Mounted on
> /dev/sda2 5.8G 1.5G 4.3G 26% /
> tmpfs 2.0G 0 2.0G 0% /lib/init/rw
> udev 10M 140K 9.9M 2% /dev
> tmpfs 2.0G 0 2.0G 0% /dev/shm
> atom:~# cd /
> atom:/# ls
> bin cdrom etc lib media nfs proc sbin srv tmp var
> boot dev home lib64 mnt opt root selinux sys usr
> atom:/# dd if=/dev/zero of=bigfile bs=1M count=4000
> 4000+0 records in
> 4000+0 records out
> 4194304000 bytes (4.2 GB) copied, 135.536 s, 30.9 MB/s
> atom:/# df -h
> Filesystem Size Used Avail Use% Mounted on
> /dev/sda2 5.8G 5.4G 350M 95% /
> tmpfs 2.0G 0 2.0G 0% /lib/init/rw
> udev 10M 140K 9.9M 2% /dev
> tmpfs 2.0G 0 2.0G 0% /dev/shm
> atom:/# rm bigfile
>
> However, after some amount of time, the errors occur below, is this USB
> stick failing? Since it has no SMART, is there any other way to verify
> the 'health' of a USB stick?
None that I know of.
> Mar 18 07:55:12 atom [ 10.034310] e1000e 0000:03:00.0: eth1: 10/100 speed: disabling TSO
>
> [ .. no errors .. ]
>
> Mar 18 08:32:44 atom [ 2261.883848] usb 1-1: USB disconnect, address 2
> Mar 18 08:32:44 atom [ 2261.884465] Buffer I/O error on device sda2, logical block 1317256
The stick didn't "fail" in any obvious way, but for some reason it was
disconnected from the USB bus. (If it initiated that disconnect by
itself, I guess you could consider that a failure.) Maybe it was
something as simple as overheating causing a loss of electrical contact
between the connector and the pins in the USB port.
...
> Mar 18 08:33:06 atom [ 2283.963059] usb 1-1: new high speed USB device using ehci_hcd and address 4
> Mar 18 08:33:06 atom [ 2284.080647] usb 1-1: New USB device found, idVendor=0325, idProduct=ac02
> Mar 18 08:33:06 atom [ 2284.080707] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> Mar 18 08:33:06 atom [ 2284.080752] usb 1-1: Product: R2_TURBO
> Mar 18 08:33:06 atom [ 2284.080794] usb 1-1: Manufacturer: OCZ Technology
> Mar 18 08:33:06 atom [ 2284.080831] usb 1-1: SerialNumber: (removed)
And then 22 seconds later it reconnected.
Alan Stern
On Friday 18 March 2011, Tim Soderstrom wrote:
> >
> > However, after some amount of time, the errors occur below, is this USB
> > stick failing? Since it has no SMART, is there any other way to verify
> > the 'health' of a USB stick?
>
> What prompted you to go with XFS over, say, ext2? The journal will generally
> cause quite a bit more writes onto your USB device. I use ext2 on my CF card
> in my NAS for that reason (the spinning media is on XFS of course). I know
> that's not an answer to your problem but thought I would add it as a suggestion :)
Using ext2 on flash media instead of ext3 or other file systems is
recommended a lot, but the situation is actually much more complex.
In https://lwn.net/Articles/428584/, I explain how these things work
under the cover. For a drive that can only have very few erase blocks
open, using a journaled file system will always mean thrashing, but
for drives with more open erase blocks, it's probably better to
use a journal than not.
I still need to do simulations to figure out how this exactly
ends up on various file systems, and I had not considered XFS
so far.
Getting back to the rogiinal question, I'd recommend testing the
stick by doing raw accesses instead of a file system. A simple
dd if=/dev/sdX of=/dev/zero iflag=direct bs=4M
will read the entire stick and report any errors. The corresponding
dd of=/dev/zero of=/dev/sdX oflag=direct bs=4M
writes the entire stick. Some media won't report errors on write,
though, so this might not help you at all.
I'm also interested in results from flashbench
(git://git.linaro.org/people/arnd/flashbench.git, e.g. like
http://lists.linaro.org/pipermail/flashbench-results/2011-March/000039.html)
That might help explain how the stick failed.
Arnd
Arnd
On Mar 18, 2011, at 10:59 AM, Arnd Bergmann wrote:
> On Friday 18 March 2011, Tim Soderstrom wrote:
>
>>>
>>> However, after some amount of time, the errors occur below, is this USB
>>> stick failing? Since it has no SMART, is there any other way to verify
>>> the 'health' of a USB stick?
>>
>> What prompted you to go with XFS over, say, ext2? The journal will generally
>> cause quite a bit more writes onto your USB device. I use ext2 on my CF card
>> in my NAS for that reason (the spinning media is on XFS of course). I know
>> that's not an answer to your problem but thought I would add it as a suggestion :)
>
> Using ext2 on flash media instead of ext3 or other file systems is
> recommended a lot, but the situation is actually much more complex.
> In https://lwn.net/Articles/428584/, I explain how these things work
> under the cover. For a drive that can only have very few erase blocks
> open, using a journaled file system will always mean thrashing, but
> for drives with more open erase blocks, it's probably better to
> use a journal than not.
Wow that's a great article, thanks for the link!
Tim
On Fri, 18 Mar 2011, Tim Soderstrom wrote:
>
> On Mar 18, 2011, at 10:08 AM, Justin Piszcz wrote:
>
>> Hi,
>>
>> I can write to just about the entire USB stick, with no errors:
>>
>> atom:~# df -h
>> Filesystem Size Used Avail Use% Mounted on
>> /dev/sda2 5.8G 1.5G 4.3G 26% /
>> tmpfs 2.0G 0 2.0G 0% /lib/init/rw
>> udev 10M 140K 9.9M 2% /dev
>> tmpfs 2.0G 0 2.0G 0% /dev/shm
>> atom:~# cd /
>> atom:/# ls
>> bin cdrom etc lib media nfs proc sbin srv tmp var
>> boot dev home lib64 mnt opt root selinux sys usr
>> atom:/# dd if=/dev/zero of=bigfile bs=1M count=4000
>> 4000+0 records in
>> 4000+0 records out
>> 4194304000 bytes (4.2 GB) copied, 135.536 s, 30.9 MB/s
>> atom:/# df -h
>> Filesystem Size Used Avail Use% Mounted on
>> /dev/sda2 5.8G 5.4G 350M 95% /
>> tmpfs 2.0G 0 2.0G 0% /lib/init/rw
>> udev 10M 140K 9.9M 2% /dev
>> tmpfs 2.0G 0 2.0G 0% /dev/shm
>> atom:/# rm bigfile
>>
>> However, after some amount of time, the errors occur below, is this USB
>> stick failing? Since it has no SMART, is there any other way to verify
>> the 'health' of a USB stick?
>
> What prompted you to go with XFS over, say, ext2? The journal will generally cause quite a bit more writes onto your USB device. I use ext2 on my CF card in my NAS for that reason (the spinning media is on XFS of course). I know that's not an answer to your problem but thought I would add it as a suggestion :)
>
Hi,
Just habit I suppose.. (XFS). Looks like EXT2 is the correct solution here,
or ext4 w/nojournal (if Google's patch is in the kernel). I have to read
the lwn.net article though.
Justin
On Fri, 18 Mar 2011, Alan Stern wrote:
> On Fri, 18 Mar 2011, Justin Piszcz wrote:
>
>> Hi,
>>
>> I can write to just about the entire USB stick, with no errors:
>>
>> atom:~# df -h
>> Filesystem Size Used Avail Use% Mounted on
>> /dev/sda2 5.8G 1.5G 4.3G 26% /
>> tmpfs 2.0G 0 2.0G 0% /lib/init/rw
>> udev 10M 140K 9.9M 2% /dev
>> tmpfs 2.0G 0 2.0G 0% /dev/shm
>> atom:~# cd /
>> atom:/# ls
>> bin cdrom etc lib media nfs proc sbin srv tmp var
>> boot dev home lib64 mnt opt root selinux sys usr
>> atom:/# dd if=/dev/zero of=bigfile bs=1M count=4000
>> 4000+0 records in
>> 4000+0 records out
>> 4194304000 bytes (4.2 GB) copied, 135.536 s, 30.9 MB/s
>> atom:/# df -h
>> Filesystem Size Used Avail Use% Mounted on
>> /dev/sda2 5.8G 5.4G 350M 95% /
>> tmpfs 2.0G 0 2.0G 0% /lib/init/rw
>> udev 10M 140K 9.9M 2% /dev
>> tmpfs 2.0G 0 2.0G 0% /dev/shm
>> atom:/# rm bigfile
>>
>> However, after some amount of time, the errors occur below, is this USB
>> stick failing? Since it has no SMART, is there any other way to verify
>> the 'health' of a USB stick?
>
> None that I know of.
>
>> Mar 18 07:55:12 atom [ 10.034310] e1000e 0000:03:00.0: eth1: 10/100 speed: disabling TSO
>>
>> [ .. no errors .. ]
>>
>> Mar 18 08:32:44 atom [ 2261.883848] usb 1-1: USB disconnect, address 2
>> Mar 18 08:32:44 atom [ 2261.884465] Buffer I/O error on device sda2, logical block 1317256
>
> The stick didn't "fail" in any obvious way, but for some reason it was
> disconnected from the USB bus. (If it initiated that disconnect by
> itself, I guess you could consider that a failure.) Maybe it was
> something as simple as overheating causing a loss of electrical contact
> between the connector and the pins in the USB port.
It is possible, but the box is kept cool:
w83627dhg-isa-0ca0
Adapter: ISA adapter
Vcore: +1.16 V (min = +0.72 V, max = +1.39 V)
in1: +1.04 V (min = +0.94 V, max = +1.16 V)
AVCC: +3.34 V (min = +2.96 V, max = +3.63 V)
+3.3V: +3.34 V (min = +2.98 V, max = +3.63 V)
in4: +1.84 V (min = +1.62 V, max = +1.98 V)
in5: +1.26 V (min = +1.13 V, max = +1.38 V)
in6: +0.75 V (min = +0.67 V, max = +0.83 V)
3VSB: +3.30 V (min = +2.96 V, max = +3.63 V)
Vbat: +3.07 V (min = +2.96 V, max = +3.63 V)
fan1: 0 RPM (min = 727 RPM, div = 64) ALARM
fan2: 0 RPM (min = 727 RPM, div = 64) ALARM
fan3: 0 RPM (min = 727 RPM, div = 64) ALARM
fan4: 1240 RPM (min = 712 RPM, div = 8)
fan5: 0 RPM (min = 727 RPM, div = 64) ALARM
temp1: +36.0°C (high = +75.0°C, hyst = +70.0°C) sensor = thermistor
temp2: +35.5°C (high = +90.0°C, hyst = +87.0°C) sensor = diode
temp3: +19.0°C (high = +80.0°C, hyst = +75.0°C) sensor = diode
cpu0_vid: +0.000 V
coretemp-isa-0000
Adapter: ISA adapter
Core 0: +12.0°C (crit = +100.0°C)
coretemp-isa-0001
Adapter: ISA adapter
Core 1: +16.0°C (crit = +100.0°C)
>
> ...
>> Mar 18 08:33:06 atom [ 2283.963059] usb 1-1: new high speed USB device using ehci_hcd and address 4
>> Mar 18 08:33:06 atom [ 2284.080647] usb 1-1: New USB device found, idVendor=0325, idProduct=ac02
>> Mar 18 08:33:06 atom [ 2284.080707] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
>> Mar 18 08:33:06 atom [ 2284.080752] usb 1-1: Product: R2_TURBO
>> Mar 18 08:33:06 atom [ 2284.080794] usb 1-1: Manufacturer: OCZ Technology
>> Mar 18 08:33:06 atom [ 2284.080831] usb 1-1: SerialNumber: (removed)
>
> And then 22 seconds later it reconnected.
>
> Alan Stern
>
Very strange, could some USB option cause this? I guess next step is use
ext2 and a different stick in the same port to see if I can get it to recur.
Then if it happens again, try a different port.
Justin.
On Fri, 18 Mar 2011, Arnd Bergmann wrote:
> On Friday 18 March 2011, Tim Soderstrom wrote:
>
>>>
>>> However, after some amount of time, the errors occur below, is this USB
>>> stick failing? Since it has no SMART, is there any other way to verify
>>> the 'health' of a USB stick?
>>
>> What prompted you to go with XFS over, say, ext2? The journal will generally
>> cause quite a bit more writes onto your USB device. I use ext2 on my CF card
>> in my NAS for that reason (the spinning media is on XFS of course). I know
>> that's not an answer to your problem but thought I would add it as a suggestion :)
>
> Using ext2 on flash media instead of ext3 or other file systems is
> recommended a lot, but the situation is actually much more complex.
> In https://lwn.net/Articles/428584/, I explain how these things work
> under the cover. For a drive that can only have very few erase blocks
> open, using a journaled file system will always mean thrashing, but
> for drives with more open erase blocks, it's probably better to
> use a journal than not.
>
> I still need to do simulations to figure out how this exactly
> ends up on various file systems, and I had not considered XFS
> so far.
Ok, I performed all of the tests and I did not notice any type of failures,
unless I am not interpreting the results correctly..
>
> Getting back to the rogiinal question, I'd recommend testing the
> stick by doing raw accesses instead of a file system. A simple
>
> dd if=/dev/sdX of=/dev/zero iflag=direct bs=4M
root@sysresccd /root % time dd if=/dev/sda of=/dev/zero iflag=direct bs=4M
1960+0 records in
1960+0 records out
8220835840 bytes (8.2 GB) copied, 234.265 s, 35.1 MB/s
dd if=/dev/sda of=/dev/zero iflag=direct bs=4M 0.01s user 1.88s system 0% cpu 3:54.28 total
root@sysresccd /root %
>
> will read the entire stick and report any errors. The corresponding
>
> dd of=/dev/zero of=/dev/sdX oflag=direct bs=4M
.. yes I took a second backup (before wiping) before doing this (below) ..
>
> writes the entire stick. Some media won't report errors on write,
> though, so this might not help you at all.
Ok, here are the results:
root@sysresccd /root % time dd if=/dev/zero of=/dev/sda oflag=direct bs=4M
dd: writing `/dev/sda': No space left on device
1961+0 records in
1960+0 records out
8220835840 bytes (8.2 GB) copied, 283.744 s, 29.0 MB/s
dd if=/dev/zero of=/dev/sda oflag=direct bs=4M 0.01s user 7.14s system 2% cpu 4:43.75 total
root@sysresccd /root %
> I'm also interested in results from flashbench
> (git://git.linaro.org/people/arnd/flashbench.git, e.g. like
> http://lists.linaro.org/pipermail/flashbench-results/2011-March/000039.html)
> That might help explain how the stick failed.
Certainly, testing below, following this:
http://lists.linaro.org/pipermail/flashbench-results/2011-March/000039.html
# ./flashbench --open-au --open-au-nr=1 /dev/sda --blocksize=8192 --erasesize=$[2* 1024 * 1024] --random
2MiB 29.5M/s
1MiB 29.1M/s
512KiB 28.5M/s
256KiB 22.8M/s
128KiB 23.8M/s
64KiB 24.4M/s
32KiB 18.9M/s
16KiB 13.1M/s
8KiB 8.22M/s
# ./flashbench --open-au --open-au-nr=4 /dev/sda --blocksize=8192 --erasesize=$[2* 1024 * 1024] --random
2MiB 25.9M/s
1MiB 21.8M/s
512KiB 15M/s
256KiB 11.9M/s
128KiB 12.1M/s
64KiB 13.6M/s
32KiB 9.81M/s
16KiB 6.41M/s
8KiB 3.88M/s
# ./flashbench --open-au --open-au-nr=5 /dev/sda --blocksize=8192 --erasesize=$[2* 1024 * 1024] --random
2MiB 29.2M/s
1MiB 27.8M/s
512KiB 18.4M/s
256KiB 7.82M/s
128KiB 4.62M/s
64KiB 2.47M/s
32KiB 1.26M/s
16KiB 642K/s
8KiB 327K/s
#
# ./flashbench --open-au --open-au-nr=6 /dev/sda --blocksize=1024 --erasesize=$[2* 1024 * 1024] --random
2MiB 29.2M/s
1MiB 25.6M/s
512KiB 15.2M/s
256KiB 7.8M/s
128KiB 4.73M/s
64KiB 2.53M/s
32KiB 1.3M/s
16KiB 659K/s
8KiB 333K/s
^C
#
(did not run one with 7)
# ./flashbench --findfat --fat-nr=10 /dev/sda --blocksize=1024 --erasesize=$[2* 1024 * 1024] --random
2MiB 22.7M/s 19.1M/s 15.5M/s 13.1M/s 29.5M/s 29.5M/s 29.6M/s 29.6M/s 29.5M/s 29.5M/s
1MiB 20.6M/s 13.3M/s 13.3M/s 20.8M/s 18.1M/s 17.8M/s 18M/s 18.3M/s 18.8M/s 18.6M/s
512KiB 18.4M/s 18.6M/s 18.3M/s 18.1M/s 23.5M/s 23.2M/s 23.5M/s 23.5M/s 23.4M/s 23.4M/s
256KiB 26.9M/s 21.3M/s 21.2M/s 21M/s 21.1M/s 21.2M/s 21.1M/s 21.1M/s 20.6M/s 21M/s
128KiB 22.2M/s 22.3M/s 22.6M/s 21.4M/s 21.5M/s 21.3M/s 21.6M/s 21.3M/s 21.4M/s 21.4M/s
64KiB 23.9M/s 22.6M/s 22.9M/s 23M/s 22.5M/s 22.4M/s 22.4M/s 22.4M/s 22.5M/s 22.4M/s
32KiB 18.2M/s 18.3M/s 18.3M/s 18.3M/s 18.3M/s 18.4M/s 18.3M/s 18.2M/s 18.3M/s 18.3M/s
16KiB 12.9M/s 12.9M/s 13M/s 13M/s 12.9M/s 13M/s 12.9M/s 12.9M/s 12.9M/s 12.9M/s
8KiB 8.14M/s 8.15M/s 8.15M/s 8.15M/s 8.15M/s 8.14M/s 8.14M/s 8.15M/s 8.15M/s 8.06M/s
4KiB 4.07M/s 4.08M/s 4.07M/s 4.06M/s 4.04M/s 4.04M/s 4.04M/s 4.04M/s 4.04M/s 4.04M/s
2KiB 2.02M/s 2.02M/s 2.02M/s 2.02M/s 2.02M/s 2.01M/s 2.01M/s 2.01M/s 2.01M/s 2.02M/s
1KiB 956K/s 954K/s 956K/s 953K/s 947K/s 947K/s 947K/s 950K/s 947K/s 948K/s
Ideas?
Justin.
On Friday 18 March 2011 18:45:34 Justin Piszcz wrote:
> On Fri, 18 Mar 2011, Arnd Bergmann wrote:
> > Getting back to the rogiinal question, I'd recommend testing the
> > stick by doing raw accesses instead of a file system. A simple
>
> Ok, here are the results:
>
> root@sysresccd /root % time dd if=/dev/zero of=/dev/sda oflag=direct bs=4M
> dd: writing `/dev/sda': No space left on device
> 1961+0 records in
> 1960+0 records out
> 8220835840 bytes (8.2 GB) copied, 283.744 s, 29.0 MB/s
Ok, so no immediate problem there.
> > I'm also interested in results from flashbench
> > (git://git.linaro.org/people/arnd/flashbench.git, e.g. like
> > http://lists.linaro.org/pipermail/flashbench-results/2011-March/000039.html)
> > That might help explain how the stick failed.
>
> Certainly, testing below, following this:
> http://lists.linaro.org/pipermail/flashbench-results/2011-March/000039.html
I'm sorry, I should have been more specific. Unfortunately, running flashbench
is not very user friendly yet.
The results indicate that the device does not have a 2 MB erase block size
but rather 4 or 8, which is more common on 8 GB media.
> # ./flashbench --open-au --open-au-nr=1 /dev/sda --blocksize=8192 --erasesize=$[2* 1024 * 1024] --random
> 2MiB 29.5M/s
> 1MiB 29.1M/s
> 512KiB 28.5M/s
> 256KiB 22.8M/s
> 128KiB 23.8M/s
> 64KiB 24.4M/s
> 32KiB 18.9M/s
> 16KiB 13.1M/s
> 8KiB 8.22M/s
>
> # ./flashbench --open-au --open-au-nr=4 /dev/sda --blocksize=8192 --erasesize=$[2* 1024 * 1024] --random
> 2MiB 25.9M/s
> 1MiB 21.8M/s
> 512KiB 15M/s
> 256KiB 11.9M/s
> 128KiB 12.1M/s
> 64KiB 13.6M/s
> 32KiB 9.81M/s
> 16KiB 6.41M/s
> 8KiB 3.88M/s
The numbers are jumping around a bit with the incorrectly guessed erasesize.
These values should be more like the ones in the first test. Can you rerun
with --erasesize=$[4 * 1024 * 1024]?
Also, what is the output of 'lsusb' for this stick? I'd like to add the
data to https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Projects/FlashCardSurvey
> # ./flashbench --open-au --open-au-nr=5 /dev/sda --blocksize=8192 --erasesize=$[2* 1024 * 1024] --random
> 2MiB 29.2M/s
> 1MiB 27.8M/s
> 512KiB 18.4M/s
> 256KiB 7.82M/s
> 128KiB 4.62M/s
> 64KiB 2.47M/s
> 32KiB 1.26M/s
> 16KiB 642K/s
> 8KiB 327K/s
This is where your drive stops coping with the accesses: Writing small
blocks to four different erase blocks (2MB for the test, probably
larger) works fine, but writing to five of them is devestating for
performance, going from 30 MB/s to 300 KB/s, or lower if you were
to write smaller than 8 KB blocks.
The cutoff at --open-au-nr=4 is coincidentally the same as for the
SD card I was testing. This is what happens in the animation in
http://lwn.net/Articles/428799/. The example given there is for
a drive that can only have two open AUs (allocation units aka
erase blocks), while yours does 4.
> (did not run one with 7)
Note that the test results I had with 6 and 7 are without --random,
so the cut-off there was higher for that card when writing an
multiple erase blocks from start to finish instead of writing random
sectors inside of them.
> # ./flashbench --findfat --fat-nr=10 /dev/sda --blocksize=1024 --erasesize=$[2* 1024 * 1024] --random
> 2MiB 22.7M/s 19.1M/s 15.5M/s 13.1M/s 29.5M/s 29.5M/s 29.6M/s 29.6M/s 29.5M/s 29.5M/s
> 1MiB 20.6M/s 13.3M/s 13.3M/s 20.8M/s 18.1M/s 17.8M/s 18M/s 18.3M/s 18.8M/s 18.6M/s
> 512KiB 18.4M/s 18.6M/s 18.3M/s 18.1M/s 23.5M/s 23.2M/s 23.5M/s 23.5M/s 23.4M/s 23.4M/s
> 256KiB 26.9M/s 21.3M/s 21.2M/s 21M/s 21.1M/s 21.2M/s 21.1M/s 21.1M/s 20.6M/s 21M/s
> 128KiB 22.2M/s 22.3M/s 22.6M/s 21.4M/s 21.5M/s 21.3M/s 21.6M/s 21.3M/s 21.4M/s 21.4M/s
> 64KiB 23.9M/s 22.6M/s 22.9M/s 23M/s 22.5M/s 22.4M/s 22.4M/s 22.4M/s 22.5M/s 22.4M/s
> 32KiB 18.2M/s 18.3M/s 18.3M/s 18.3M/s 18.3M/s 18.4M/s 18.3M/s 18.2M/s 18.3M/s 18.3M/s
> 16KiB 12.9M/s 12.9M/s 13M/s 13M/s 12.9M/s 13M/s 12.9M/s 12.9M/s 12.9M/s 12.9M/s
> 8KiB 8.14M/s 8.15M/s 8.15M/s 8.15M/s 8.15M/s 8.14M/s 8.14M/s 8.15M/s 8.15M/s 8.06M/s
> 4KiB 4.07M/s 4.08M/s 4.07M/s 4.06M/s 4.04M/s 4.04M/s 4.04M/s 4.04M/s 4.04M/s 4.04M/s
> 2KiB 2.02M/s 2.02M/s 2.02M/s 2.02M/s 2.02M/s 2.01M/s 2.01M/s 2.01M/s 2.01M/s 2.02M/s
> 1KiB 956K/s 954K/s 956K/s 953K/s 947K/s 947K/s 947K/s 950K/s 947K/s 948K/s
>
One thing that is very clear from this is that this stick has a page size
of 8KB, and that it requires at least 64 KB transfers for the maximum speed.
If your partition is not aligned to 8 KB or more (better: to the erase
block size, e.g. 4 MB) or if the file system writes smaller than 8 KB
naturally aligned blocks at once, the drive has to do read-modify-write
cycles that severely impact performance and the expected life-time.
I cannot see any block that is optimzied for storing the FAT, which is
good, as this means that the manufacturer did not exclusively design
the stick for FAT32, as is normally the case with flash memory cards.
For this stick, I would strongly recommend creating the file system
in a way that writes at least 16 KB naturally aligned blocks at all
times, but I don't know if that's supported by XFS.
Also, the limitation of forcing a garbage collection when writing to
more than four 4 MB (or so) segments may be a problem, depending on
how XFS stores its metadata. The good news is that it can do random
write access inside of the erase blocks.
Arnd
On Fri, 18 Mar 2011, Arnd Bergmann wrote:
> On Friday 18 March 2011 18:45:34 Justin Piszcz wrote:
>> On Fri, 18 Mar 2011, Arnd Bergmann wrote:
>>> Getting back to the rogiinal question, I'd recommend testing the
>>> stick by doing raw accesses instead of a file system. A simple
>>
>> Ok, here are the results:
>>
>> root@sysresccd /root % time dd if=/dev/zero of=/dev/sda oflag=direct bs=4M
>> dd: writing `/dev/sda': No space left on device
>> 1961+0 records in
>> 1960+0 records out
>> 8220835840 bytes (8.2 GB) copied, 283.744 s, 29.0 MB/s
>
> Ok, so no immediate problem there.
>
>>> I'm also interested in results from flashbench
>>> (git://git.linaro.org/people/arnd/flashbench.git, e.g. like
>>> http://lists.linaro.org/pipermail/flashbench-results/2011-March/000039.html)
>>> That might help explain how the stick failed.
>>
>> Certainly, testing below, following this:
>> http://lists.linaro.org/pipermail/flashbench-results/2011-March/000039.html
>
> I'm sorry, I should have been more specific. Unfortunately, running flashbench
> is not very user friendly yet.
>
> The results indicate that the device does not have a 2 MB erase block size
> but rather 4 or 8, which is more common on 8 GB media.
>
>> # ./flashbench --open-au --open-au-nr=1 /dev/sda --blocksize=8192 --erasesize=$[2* 1024 * 1024] --random
>> 2MiB 29.5M/s
>> 1MiB 29.1M/s
>> 512KiB 28.5M/s
>> 256KiB 22.8M/s
>> 128KiB 23.8M/s
>> 64KiB 24.4M/s
>> 32KiB 18.9M/s
>> 16KiB 13.1M/s
>> 8KiB 8.22M/s
>>
>> # ./flashbench --open-au --open-au-nr=4 /dev/sda --blocksize=8192 --erasesize=$[2* 1024 * 1024] --random
>> 2MiB 25.9M/s
>> 1MiB 21.8M/s
>> 512KiB 15M/s
>> 256KiB 11.9M/s
>> 128KiB 12.1M/s
>> 64KiB 13.6M/s
>> 32KiB 9.81M/s
>> 16KiB 6.41M/s
>> 8KiB 3.88M/s
>
> The numbers are jumping around a bit with the incorrectly guessed erasesize.
> These values should be more like the ones in the first test. Can you rerun
> with --erasesize=$[4 * 1024 * 1024]?
Hi, I put the box back into production with ext2, if it fails again I can
re-run.
>
> Also, what is the output of 'lsusb' for this stick? I'd like to add the
> data to https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Projects/FlashCardSurvey
Sure,
Bus 001 Device 002: ID 0325:ac02 OCZ Technology Inc ATV Turbo / Rally2 Dual Channel USB 2.0 Flash Drive
>
>> # ./flashbench --open-au --open-au-nr=5 /dev/sda --blocksize=8192 --erasesize=$[2* 1024 * 1024] --random
>> 2MiB 29.2M/s
>> 1MiB 27.8M/s
>> 512KiB 18.4M/s
>> 256KiB 7.82M/s
>> 128KiB 4.62M/s
>> 64KiB 2.47M/s
>> 32KiB 1.26M/s
>> 16KiB 642K/s
>> 8KiB 327K/s
>
> This is where your drive stops coping with the accesses: Writing small
> blocks to four different erase blocks (2MB for the test, probably
> larger) works fine, but writing to five of them is devestating for
> performance, going from 30 MB/s to 300 KB/s, or lower if you were
> to write smaller than 8 KB blocks.
>
> The cutoff at --open-au-nr=4 is coincidentally the same as for the
> SD card I was testing. This is what happens in the animation in
> http://lwn.net/Articles/428799/. The example given there is for
> a drive that can only have two open AUs (allocation units aka
> erase blocks), while yours does 4.
>
>> (did not run one with 7)
>
> Note that the test results I had with 6 and 7 are without --random,
> so the cut-off there was higher for that card when writing an
> multiple erase blocks from start to finish instead of writing random
> sectors inside of them.
>
>> # ./flashbench --findfat --fat-nr=10 /dev/sda --blocksize=1024 --erasesize=$[2* 1024 * 1024] --random
>> 2MiB 22.7M/s 19.1M/s 15.5M/s 13.1M/s 29.5M/s 29.5M/s 29.6M/s 29.6M/s 29.5M/s 29.5M/s
>> 1MiB 20.6M/s 13.3M/s 13.3M/s 20.8M/s 18.1M/s 17.8M/s 18M/s 18.3M/s 18.8M/s 18.6M/s
>> 512KiB 18.4M/s 18.6M/s 18.3M/s 18.1M/s 23.5M/s 23.2M/s 23.5M/s 23.5M/s 23.4M/s 23.4M/s
>> 256KiB 26.9M/s 21.3M/s 21.2M/s 21M/s 21.1M/s 21.2M/s 21.1M/s 21.1M/s 20.6M/s 21M/s
>> 128KiB 22.2M/s 22.3M/s 22.6M/s 21.4M/s 21.5M/s 21.3M/s 21.6M/s 21.3M/s 21.4M/s 21.4M/s
>> 64KiB 23.9M/s 22.6M/s 22.9M/s 23M/s 22.5M/s 22.4M/s 22.4M/s 22.4M/s 22.5M/s 22.4M/s
>> 32KiB 18.2M/s 18.3M/s 18.3M/s 18.3M/s 18.3M/s 18.4M/s 18.3M/s 18.2M/s 18.3M/s 18.3M/s
>> 16KiB 12.9M/s 12.9M/s 13M/s 13M/s 12.9M/s 13M/s 12.9M/s 12.9M/s 12.9M/s 12.9M/s
>> 8KiB 8.14M/s 8.15M/s 8.15M/s 8.15M/s 8.15M/s 8.14M/s 8.14M/s 8.15M/s 8.15M/s 8.06M/s
>> 4KiB 4.07M/s 4.08M/s 4.07M/s 4.06M/s 4.04M/s 4.04M/s 4.04M/s 4.04M/s 4.04M/s 4.04M/s
>> 2KiB 2.02M/s 2.02M/s 2.02M/s 2.02M/s 2.02M/s 2.01M/s 2.01M/s 2.01M/s 2.01M/s 2.02M/s
>> 1KiB 956K/s 954K/s 956K/s 953K/s 947K/s 947K/s 947K/s 950K/s 947K/s 948K/s
>>
>
> One thing that is very clear from this is that this stick has a page size
> of 8KB, and that it requires at least 64 KB transfers for the maximum speed.
>
> If your partition is not aligned to 8 KB or more (better: to the erase
> block size, e.g. 4 MB) or if the file system writes smaller than 8 KB
> naturally aligned blocks at once, the drive has to do read-modify-write
> cycles that severely impact performance and the expected life-time.
>
> I cannot see any block that is optimzied for storing the FAT, which is
> good, as this means that the manufacturer did not exclusively design
> the stick for FAT32, as is normally the case with flash memory cards.
>
> For this stick, I would strongly recommend creating the file system
> in a way that writes at least 16 KB naturally aligned blocks at all
> times, but I don't know if that's supported by XFS.
>
> Also, the limitation of forcing a garbage collection when writing to
> more than four 4 MB (or so) segments may be a problem, depending on
> how XFS stores its metadata. The good news is that it can do random
> write access inside of the erase blocks.
>
> Arnd
>
Thanks for your response, per the recommendations earlier I've migrated to ext2
and am running that now and I still need to read that article.
Justin.
On Fri, 18 Mar 2011, Justin Piszcz wrote:
> > The stick didn't "fail" in any obvious way, but for some reason it was
> > disconnected from the USB bus. (If it initiated that disconnect by
> > itself, I guess you could consider that a failure.) Maybe it was
> > something as simple as overheating causing a loss of electrical contact
> > between the connector and the pins in the USB port.
>
> It is possible, but the box is kept cool:
Then something else caused the disconnection. Maybe a bug in the USB
stick's firmware.
> >> Mar 18 08:33:06 atom [ 2283.963059] usb 1-1: new high speed USB device using ehci_hcd and address 4
> >> Mar 18 08:33:06 atom [ 2284.080647] usb 1-1: New USB device found, idVendor=0325, idProduct=ac02
> >> Mar 18 08:33:06 atom [ 2284.080707] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> >> Mar 18 08:33:06 atom [ 2284.080752] usb 1-1: Product: R2_TURBO
> >> Mar 18 08:33:06 atom [ 2284.080794] usb 1-1: Manufacturer: OCZ Technology
> >> Mar 18 08:33:06 atom [ 2284.080831] usb 1-1: SerialNumber: (removed)
> >
> > And then 22 seconds later it reconnected.
> >
> > Alan Stern
> >
>
> Very strange, could some USB option cause this?
No.
> I guess next step is use
> ext2 and a different stick in the same port to see if I can get it to recur.
> Then if it happens again, try a different port.
Okay, go ahead and see what happens.
Alan Stern
On Friday 18 March 2011 20:26:46 Justin Piszcz wrote:
> > The numbers are jumping around a bit with the incorrectly guessed erasesize.
> > These values should be more like the ones in the first test. Can you rerun
> > with --erasesize=$[4 * 1024 * 1024]?
> Hi, I put the box back into production with ext2, if it fails again I can
> re-run.
Ok. Did you make sure to get the partition table right? It's
rather tricky with fdisk, since it normally doesn't align
to 4 MB. You can see this using 'fdisk -l -u /dev/sda'.
> > Also, what is the output of 'lsusb' for this stick? I'd like to add the
> > data to https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Projects/FlashCardSurvey
> Sure,
> Bus 001 Device 002: ID 0325:ac02 OCZ Technology Inc ATV Turbo / Rally2 Dual Channel USB 2.0 Flash Drive
>
Added now, thanks!
Do you also have the product name for this?
Arnd
On Fri, 18 Mar 2011, Arnd Bergmann wrote:
> On Friday 18 March 2011 20:26:46 Justin Piszcz wrote:
>>> The numbers are jumping around a bit with the incorrectly guessed erasesize.
>>> These values should be more like the ones in the first test. Can you rerun
>>> with --erasesize=$[4 * 1024 * 1024]?
>> Hi, I put the box back into production with ext2, if it fails again I can
>> re-run.
>
> Ok. Did you make sure to get the partition table right? It's
> rather tricky with fdisk, since it normally doesn't align
> to 4 MB. You can see this using 'fdisk -l -u /dev/sda'.
Erm, probably not right then..
Disk /dev/sda: 8220 MB, 8220835840 bytes
154 heads, 56 sectors/track, 1861 cylinders, total 16056320 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x99df019d
Device Boot Start End Blocks Id System
/dev/sda1 2048 16056319 8027136 83 Linux
>
>>> Also, what is the output of 'lsusb' for this stick? I'd like to add the
>>> data to https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Projects/FlashCardSurvey
>> Sure,
>> Bus 001 Device 002: ID 0325:ac02 OCZ Technology Inc ATV Turbo / Rally2 Dual Channel USB 2.0 Flash Drive
>>
>
> Added now, thanks!
>
> Do you also have the product name for this?
10007937 OCZ OCZUSBR2TDC-8GB 8GB Rally2 Turbo USB 2.0 Flash Drive Retail
Was $116.99 on 01-05-2009.
Was purported (at the time) to be one of the fastest USB sticks available,
according to benchmarks.
>
> Arnd
>
On Friday 18 March 2011 20:51:47 Justin Piszcz wrote:
> Disk /dev/sda: 8220 MB, 8220835840 bytes
> 154 heads, 56 sectors/track, 1861 cylinders, total 16056320 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x99df019d
>
> Device Boot Start End Blocks Id System
> /dev/sda1 2048 16056319 8027136 83 Linux
Ok, so it has the normal 1 MB alignment. That is not too
bad then, no immediate reason to reformat, because ext2
doesn't understand the concept of erase blocks.
If the partition was completely misaligned (old fdisk would
start the first partition at sector 63 instead of 2048),
that would be a much more significant problem.
> >>> Also, what is the output of 'lsusb' for this stick? I'd like to add the
> >>> data to https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Projects/FlashCardSurvey
> >> Sure,
> >> Bus 001 Device 002: ID 0325:ac02 OCZ Technology Inc ATV Turbo / Rally2 Dual Channel USB 2.0 Flash Drive
> >>
> >
> > Added now, thanks!
> >
> > Do you also have the product name for this?
> 10007937 OCZ OCZUSBR2TDC-8GB 8GB Rally2 Turbo USB 2.0 Flash Drive Retail
> Was $116.99 on 01-05-2009.
>
> Was purported (at the time) to be one of the fastest USB sticks available,
> according to benchmarks.
>
Ok, thanks for the detailed information.
Arnd