Slashdot Mirror
USB Flash Drive Life Varies Up To 10 Times
Lucas123 writes "Differences in the type of memory and I/O controllers used in USB drives can make one device perform two or three times faster and last 10 times longer than another, even if both sport the USB 2.0 logo, according to a Computerworld story. While a slow USB drive may be fine for moving a few dozen megabytes of files around, when you get into larger data transfers, that's when bandwidth contrictions become noticeable. In 2009, controller manufacturers are expected to begin shipping drives with dual- and even four-channel controllers, which will increase speeds even for slower drives."
Yes, there is. But those are designed for raw access to the flash medium. The drive's controller provides a facade of having a whatever you formatted it as.
http://www.computerworld.com/action/article.do?command=printArticleBasic&articleId=9093718
I am literally 3000 tokens away from the chaotic crossbow --Stephen
Because SLC is both faster and more durable than MLC?
If J.K.R wrote Windows: Puteulanus fenestra mortalis!
db
I am literally 3000 tokens away from the chaotic crossbow --Stephen
There is a Journalled Flash File System.
exFAT isn't 'designed for USB flash devices'. Filesystems in fact don't need to be 'designed for USB flash devices' because those devices (assuming they last more than a couple of days) do wear levelling under the filesystem layer. It's a hacked up version of FAT that works past on drives bigger than 2TB or files bigger than 4GB. Since it's non back compatible and Microsoft have a new found business model of IP licensing I suspect there won't be any third party implementations. Curently there isn't a spec published for exFAT and it would be easier to patent some key part of a new filesystem than one which is back compatible with FAT.
Mind you it's still free in the sense that you don't pay for it. I'm just annoyed by people using "free software" as a synonym of the business model they favour and expect everyone to know what they mean. Microsoft could claim according to the dictionary that exFAT is free and they'd be right. The FSF doesn't own the word and can't define it. But the exFAT specification is not published (the Sun version of Open Systems) and even if it were the standard would most likely not be an open one in the sense that you don't need a license to implement it (the PC industry criteria for an Open System). Maybe it will be of course, I haven't heard a statement from Microsoft on exFAT openness and licensing.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Mod parent up! This is the heart of the problem right there: manufacturers don't write whether the USB drive (or SD card, or any other Flash RAM device) uses SLC or MLC Flash RAM. But that's the main difference. SLC Flash will survive 100.000 write/erase cycles, MLC only about 5000. That's a HUGE difference. Especially if you use the USB drive to host an OS that likes logging a lot. Each log write implies the whole Flash RAM block (usually 128 KB) to be erased and then written to.
Logging is the Flash RAM killer.
And Kingston and Sandisk should start putting "SLC" or "MLC" on their products, so we techies know whether they are worth the double price.
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
I mean USB hard drives. You may not have heard of them, but they exist. I use one.
You evidently did not RTFA. The first sentence is:
Most USB 2.0 flash drives look the same, but that doesn't mean they perform the same.The summary does not use the word flash, at all.
I was not saying "RTFA", I was saying: 1) Your assumption is correct
2) The summary should have made it clear so you did not need to make an assumption.
I assume the idiot who modded my comment flamebait also misread it the same way you did. Did you bother reading my comment and the parent properly before replying?
Well look for the ones from reputable companies that sell themselves on speed.
Like Corsair, OCZ or Patriot sticks. If you do your research on the net first then you'll be ok. It's when you walk into a store and they have a selection af candy coloured novelty thumb drives, that's when you're going to get shafted.
Personally I like the Patriot Xporter XT, I use it as a main disk on my NSLU2 debian box. It's not quite as quick as a normal HDD, but it's not bad. Corsair's voyager range are the defacto standard on fast, high capacity USB sticks right now though.
I was just discussing this the other day, and my friend found this: http://www.kingston.com/ukroot/flash/flashendurance.asp
Escher was the first MC and Giger invented the HR department.
Corsair were awesome till a few months ago when they dumped SLC. My 16GB Voyager GT is a stick of shit. Oh yeah, streaming performance is great at 25MB/sec and random reads are pretty good too. Streaming writes are better than average at around 15MB/sec. But for random writes it's just awful. How does 10-20 writes per second sound? Crap? It is.
/my/linux/source/Documentation/block.
I tried to use one as the boot drive in my Eee PC and it was glacial. There also seemed to be some kind of pathological interaction between the MCL Voyager GT and Linux's CFQ IO scheduler - when performing a lot of writes the machine would lock solid for several seconds at a time, it looked like reads were being squeezed out. I never did boil it down to a clean test case though. Switching to the deadline scheduler improved matters substantially. While investigating that I realised Linux doesn't have an optimal scheduler for flash drives, they're all built around reducing and consolidating head seeks. no-op (which as the name suggests is just a FIFO with no real scheduling at all) is the fastest scheduler for USB flash, but you get no fair scheduling at all - you have to wait for that 500MB write to finish before your 100-byte read gets its turn. At least some of no-op's better performance is down to it not being anticipatory - it doesn't wait a few milliseconds after an IO to see if the process that requested the previous read/write requests another near by. That's just a waste of time with flash which doesn't have a physical head to seek.
There's a fair bit of tuning you can do at runtime with Linux's IO schedulers, read the docs in
If you want fast, look at the old, 8GB SLC Voyager GTs. 30MB/sec read, 25MB/sec headline figures don't sound that much better, but in the real world they can be 3x faster at writes than the newer MLC models thanks to overwhelmingly better random write performance.
Chernobyl 'not a wildlife haven' - BBC News
a) Sony Tiny 2GB: 6.2 MB/sec
b) SanDisk Cruzer 2GB: 7.1 MB/sec
c) Patriot Xporter 2G: 14.2 MB/sec
d) Patriot Xporter 8G: 11.7 MB/sec
e) PQI 4GB: 1.5 MB/sec
a & b seem like "typical" drives. c was supposed to be fast, and it is! I liked it so much I bought d. Drive e was a big mistake - impulse buy without knowing the specs. It is too slow to use (45 minutes to fill it up.)
Alas, the Patriot 2GB just went in under RMA yesterday. It was the most used, but became unreliable after 18 months.
The crappy PQI stick, by far, has the nicest case - anodized blue aluminum. The Patriot units are kind of bulky rubbery things that are often too fat to fit next to an in-use usb port. I wish they were smaller.
The Sony Micro Vault Tiny units are the best form factor - the size of a thumbnail stuck to just the guts of a usb connector. This unit is great for plugging into the front of the DVD player without fear that someone will walk into it hanging out the front of the stereo shelves.
Anyhow, I will never buy a flash drive again without looking at reviews and speed ratings to at least have some hope that it is no worse than average, and I will pay extra for faster.
This issue is a bit more complicated than you think.
I touched on this in an earlier post, but I experienced the same thing and tracked it down to the CFQ IO scheduler. I never got round to making a clean test case so never submitted the bug to the kernel. My wild-ass guess is that it's assuming reads and writes take equal time when they don't with flash, which confuses its notion of "fairness". It's a pity CFQ doesn't seem to work well with flash, as it has some tasty features like being able to ionice your backup process so foreground tasks get priority. It's not just me who things CFQ aint great for flash - the default kernel on an Eee PC doesn't even have it compiled in, despite CFQ being the default scheduler for the kernel version they use (it's still the default now, you're almost certainly using it).
The IO scheduler operates at the block device level, below the page cache daemon, so in theory even when dumping cache it shouldn't starve your reads and writes out. That's pretty much the point of having a clever IO scheduler - not having to wait for a 5 GB IO to finish before you get to read the 100 byte file you're blocking on. Mostly that's what Linux's schedulers do. But CFQ with a flash drive? Not so much.
You can change the IO scheduler and tune it at runtime, which is very handy indeed. This shouldn't cause data loss, and I've not had any problems.
I'll assume your flash drive is /dev/sda, change sda as appropriate.
To see which IO scheduler you're currently using and those available in your kernel:
That shows I have all four schedulers available and CFQ is currently in use. To change it, just echo the name of the new one to that file:
I found the deadline scheduler had much better interactive performance that CFQ when booting from a flash drive.
Changing the scheduler as detailed above needs to be done after every boot and for every device. If you want to use a particular scheduler as the kernel default for all devices, either choose it at kernel compile time or pass the "elevator" parameter to your kernel in your bootloader config. For example, "elevator=deadline" makes the deadline scheduler the default. If you use grub, tag that on the end of the kernel line in /boot/grub/menu.lst.
There are tuning "knobs" for each scheduler. Read the docs in /linux/source/Documentation/block for the gory details. I tuned my system to use the deadline scheduler, group IOs less (no head seek penalty) and prioritise reads over writes (things regularly block on reads but less so on writes, which can be cached anyway - remember we're working below the level of the cache). Read the docs to understand the gory details - note that these tunables are for the deadline scheduler, they're different for different schedulers. They're not very scientifically selected and not exhaustively benchmarked so you may be able to do better. The numbers for expire are in milliseconds. This lot will dispatch IOs individually (instead of in groups of 16), do 10 reads for every write, prioritise a read a
Chernobyl 'not a wildlife haven' - BBC News