lkml.org 
[lkml]   [2011]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.38: XFS/USB/HW issue, or failing USB stick?


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.



\
 
 \ /
  Last update: 2011-03-18 20:29    [W:0.104 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site