USB Flash Drive Life Varies Up To 10 Times 192
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."
Re:FS (Score:4, Informative)
Re:FS (Score:5, Informative)
Print version here (Score:3, Informative)
Re:What does speed have to do with life? (Score:4, Informative)
Pauses when running from flash drive (Score:4, Informative)
db
Re:Pauses when running from flash drive (Score:2, Informative)
You're talking about writing an ISO filesystem with free-software tools, though-- that shouldn't be too hard to do. Assuming that you're OK with using Microsoft's cabextract tools to get inside the install files you need to modify, you can use makeisofs (or mkisofs, something along those lines) and roll it up that way. That's not the hard part.
Good luck to you.
Re:Pauses when running from flash drive (Score:3, Informative)
It's a tricky enough process that I think that you really do have to do *exactly* the steps that the howto's tell you to do, using the exact same software in the exact same way, or else some bit or other ends up not being exactly correct on the install CD that you create and it just doesn't work. I imagine that the people that came up with the howto must have gone through many, many attempts before they finally found a set of magical incantations that worked. And without using that exact same set, I essentially have to iterate in the same way to find my own set of magical incantations. And I just didn't have the time or energy for that. After trying the obvious stuff, I just gave up.
Re:Pauses when running from flash drive (Score:2, Informative)
If you ever attack it again, I'd look at WinClone for some insight. It's a piece of Mac software ostensibly dedicated to cloning NTFS partitions, but it includes a lot of helpful output on exactly which bits it's setting to make the durn thing bootable. Maybe you've already gone through that-- and maybe it's not applicable at all-- but I remember seeing it and thinking "oh, hey, that's a good place to learn about Windows boot sectors". Pretty good FAQ on the site, too.
Re:FS (Score:5, Informative)
Re:FS (Score:4, Informative)
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.
Re:I thought everyone knew this (Score:5, Informative)
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.
Re:FS (Score:4, Informative)
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:
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?
Re:MARKETING! (Score:3, Informative)
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.
Re:Pauses when running from flash drive (Score:2, Informative)
Re:I thought everyone knew this (Score:5, Informative)
I was just discussing this the other day, and my friend found this: http://www.kingston.com/ukroot/flash/flashendurance.asp [kingston.com]
Re:MARKETING! (Score:5, Informative)
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.
Re:Brand name is no guarantee (Score:3, Informative)
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.
Re:Linux runs pretty well on my cheap flash drive (Score:4, Informative)
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