Yesterday I spent much of my day doggedly figuring out a reliable way to make bootable USB flash drives which contain not only Linux but a proper Linux file system too. For some demented reason the standard, even in the Linux community, for file systems on flash drives is right out of some kind of 1990s MSDOS nightmare. With these flash drives getting quite huge these days, this simply will not do. Especially since my concept is to stop booting from hard drives which are permanently attached to computers for my day to day work. I’ve actually been doing that for about 4 months including right now. The advantage of this is that you can boot to your favorite system on any hardware you come across. I’ve even used this trick to instantly and temporarily get my Linux on a MacBook. Since I wander all over a large university campus where I manage computers in at least a dozen different locations, this is appealing to me. I’m also interested in making very secure USB based installations for managing overly sensitive things like banking and AWS. This is Brian Krebs' recommended security strategy for such things.
Eventually I developed a reliable procedure using extlinux
to boot a
Linux from an ext2 partition on a flash drive. Of course I took
complete notes on my research if you’re
interested in that sort of thing. Once I felt that procedure was
reliable I started installing Debian on a new
8GB flash drive. This seemed to go fine until it was in the middle of
reading base packages which should take no more than a couple of
minutes. The progress suddenly dropped by orders of magnitude. Very
strange. I could see that something wasn’t right. I aborted that and
did an rsync
of a complete system onto the flash drive. This worked
better and I was able to boot it and it all seemed ok.
It didn’t take long however before I started noticing some very odd performance quirks. Something was definitely going on with this drive. I had used it about 5 minutes when errors were reported which turned out to be that the drive no longer had the writable flag set. It had completely failed and was trying to let me get my data off it as its last desperate act.
$ sudo blockdev --report /dev/sdd
RO RA SSZ BSZ StartSec Size Device
ro 256 512 4096 0 8103395328 /dev/sdd
After reading the reviews of this product on Amazon I became even more intrigued. It seemed that most of the reviewers had no problem with this device but about 12% had big problems. Fortunately, or perhaps unfortunately, I had purchased a two pack and had a brand new clone of the dead one to experiment with.
I used Linux dd
to do extensive testing of the reading and writing
of characteristics of this drive. First let’s look at read
performance. I did a "skip" to 30 equidistant points on the drive and
had it read different amounts of data. The result I got with 64kB,
5MB, and 50MB reads was roughly the same as I got from the hdparm -Tt
/dev/sdd
command which showed a read throughput of between 18MB/s and
22MB/s. This was extremely consistent. At one third of the USB2.0
theoretical maximum, this drive reads fine. No problems.
Writing, however, was much more interesting. Using the same dd
technique to "seek" to 30 equidistant points over the 8GB drive, I
wrote varying amounts of random data.
Write Size |
Write Speed Range |
Average Write Speed |
50MB |
4.1MB/s-4.9MB/s |
4.6MB/s |
10MB |
2.4MB/s-5.2MB/s |
3.0MB/s |
5MB |
1.6MB/s-4.0MB/s |
1.9MB/s |
1MB |
333kB/s-707kB/s |
639kB/s |
64kB |
14.2kB/s-43.7kB/s |
42.5kB/s |
Wondering how this compares I took another USB flash drive, a Kingston DataTraveler, and ran the 64kB write test on it. It averaged 186kB/s, over 4 times faster.
The lesson is that all USB flash drives are not created equal. Caveat emptor.