Unslung 6.8 and 256MB USB sticks: RESOLVED
- I finally broke down and bought a 256MB USB memory stick, just to try to
debug the issues being reported with these small devices and Unslung 6.8.
Based on the available information (thanks to those who provided some fdisk
output from their 256MB devices), here's what's happening:
The vital bit of information is the number of cylinders on the device -- the
Linksys firmware does all its work in units of cylinders. My USB key (a
256MB Sandisk Cruzer Mini) has 1011 cylinders.
[editorial note: yes, the concept of cylinders and heads are totally
obsolete and have no application to flash memory devices, but the concept
lives on to torment all right-thinking people. This is another example of
how the sins of the fathers are visited upon the future generations.]
In order to figure out the partitioning, Linksys starts from the back and
works to the front. We will too, in the following example. One other
important bit of information: Linksys is trying to come up with the second
and third partitions as close to 128MB as possible: 256,000 blocks to be
exact. Whatever is left over becomes the first (the data) partition. This
approach works well for large disks, but let's take a look at what happens
for a 256MB device:
So, Linksys fetches the number of blocks per cylinder from the device (you
can read this from the output of "fdisk -l /dev/sda"). For my Cruzer, it's
496 blocks / cylinder. Doing the division (256,000 blocks / 496 blocks per
cylinder) yields (rounded) 516 cylinders that together can make up the
desired 128MB partition size.
Since the device contains 1011 cylinders, that means that partition #3
starts at cylinder number 495, and runs for 516 cylinders, ending at
Ok. Now the second partition: going back a further 516 cylinders from the
start of the third cylinder says that partition #2 must start at
cylinder -21 -- and run for 516 cylinders, ending at cylinder 495.
Not looked too good, huh?
But, it's not over yet -- we still need to allocate the left over space (-21
cylinders) to the first partition. Since we all know that the first
partition must start at cylinder 1 (cylinder 0 is used for the label), the
first partition must start at cylinder 1, and run for -21 cylinders.
In defense of Linksys, they *do* have code in the kernel that identifies
devices smaller than 10GB as "flash" devices, and Linksys' code will not
attempt to format them. So there really isn't any reason for their code to
handle this extreme case any more elegantly than it does -- which is to say
that since this can't ever happen, Linksys doesn't check for it, and the
hacked-up Linksys fdisk utility actually attempts to write these bogus
values to the partition table.
Ouch. It's no wonder some of the flash devices get "messed up" -- what ends
up written is enough to choke any OS that tries to make sense of the
256MB flash devices cannot be natively formatted by Unslung, at least by
[if there are those who would dispute these findings, please let us know.
in particular, the output of "fdisk -l /dev/sd<n>" would be very helpful in
trying to figure out how it might be that you can get it running. the only
scenario where I can conceive of this working is in the extreme case of very
small numbers of cylinders -- for example if the device claims to have only
3 cylinders, rounding might create a situation where the format actually
comes up with non-negative numbers. if you have such a system, please
confirm by sending along your information.]
PS: Since I now have a brand new and utterly useless 256MB memory device
lying on my desk, I shall be attempting to hack a means to override the
Linksys formatting parameters for small devices, and make this work. As
soon as I get some code working well, I'll check it in and send an email to
the nslu2-linux group. Those interested can build the head, and test with