Loading ...
Sorry, an error occurred while loading the content.

Re: Unslung 6.8 and 256MB USB sticks: RESOLVED

Expand Messages
  • brokenco
    http://www.nslu2-linux.org/wiki/HowTo/UseAMemoryStickAsMainDrive That will help you in your PostScript. ... 6.8. ... some fdisk ... device -- the ... concept
    Message 1 of 2 , Aug 4, 2006

      That will help you in your PostScript.

      --- In nslu2-linux@yahoogroups.com, "Mike \(mwester\)" <mwester@...>
      > 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
      > 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
      > 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
      > 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
      > 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
      > cylinder 1011.
      > 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
      > partition table.
      > 256MB flash devices cannot be natively formatted by Unslung, at least by
      > Unslung 6.8.
      > [if there are those who would dispute these findings, please let us
      > 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.]
      > Regards,
      > Mike (mwester)
      > PS: Since I now have a brand new and utterly useless 256MB memory
      > 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
      > unslung 6.9-alpha.
    Your message has been successfully submitted and would be delivered to recipients shortly.