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

Tips on reducing memory and running Linux on a flash device

Expand Messages
  • Martin Michlmayr
    David Härdeman has contributed two really valuable guides that will be of great interest to many NSLU2 users: - The first guide is for people running Linux on
    Message 1 of 10 , Nov 11, 2007
      David Härdeman has contributed two really valuable guides that will be
      of great interest to many NSLU2 users:

      - The first guide is for people running Linux on a flash device, such
      as a USB flash stick. Since flash only supports a limited number of
      writes, it is important to reduce the wear and tear on the underlying
      flash device. David's guide gives some practical advice of how to
      achieve this: http://www.cyrius.com/debian/nslu2/linux-on-flash.html

      - The second guide gives a few tips and tricks that can be used to
      reduce the amount of RAM a system needs. This is particularly
      interesting to NSLU2 users since 32 MB of RAM is not a lot.
      http://www.cyrius.com/debian/nslu2/reducing-memory.html

      These guides mention Debian but most of the advice applies to other
      NSLU2 firmwares and to Linux in general.
      --
      Martin Michlmayr
      http://www.cyrius.com/
    • David Given
      On Sun, 2007-11-11 at 20:51 +0100, Martin Michlmayr wrote: [...] ... Actually, I m not sure that s entirely true any more. Flash has gotten a *lot* better
      Message 2 of 10 , Nov 11, 2007
        On Sun, 2007-11-11 at 20:51 +0100, Martin Michlmayr wrote:
        [...]
        > - The first guide is for people running Linux on a flash device, such
        > as a USB flash stick. Since flash only supports a limited number of
        > writes, it is important to reduce the wear and tear on the underlying
        > flash device. David's guide gives some practical advice of how to
        > achieve this: http://www.cyrius.com/debian/nslu2/linux-on-flash.html

        Actually, I'm not sure that's entirely true any more. Flash has gotten a
        *lot* better recently.

        Finding the rewrite tolerance for a modern cheapo flash card is a little
        hard, but it seems to be about a million these days. Given that the card
        itself does wear levelling, that means that you end up with 1'000'000 *
        number of blocks worth of writes before you start running into trouble.
        So, assuming a 32kB block size (based on nothing other than my knowledge
        of flash chips), that's roughly 32 TB of writes per gigabyte.

        Of course, it's not that simple, because you only need to write once to
        a block before it needs to be written, which means this should be
        treated as a very rough guideline only. However, my NSLU2, which is
        heavily overloaded and swaps more or less constantly, claims to write
        at, on average, 1.5MB / minute. This means that a 1GB flash card should
        run it for approximately 20 million minutes, which comes out at about 40
        years. A bigger card, of course, will last longer.

        (This is all based on the underlying and potentially flawed assumption
        that my arithmetic is correct.)

        I've actually been considering buying a sacrificial thumb drive to put
        my swap partition on. Not only will seek time be faster, but it'll make
        hard disk accesses more efficient, so I think I'll get a fair speed
        improvement. And even if it turns out that I am wrong, thumb drives are
        pathetically cheap these days, so no real harm done...

        --
        ┌── dg@cowlark.com ─── http://www.cowlark.com
        ─────────────
        │ "Working with Unix is like wrestling a worthy opponent. Working with
        │ Windows is like attacking a small whining child who is carrying a
        │ .38." --- Nancy Lebovitz
      • Phil Endecott
        ... Yes. I have been using flash exclusively on everything that I own for nearly two years now with no failures that can be attributed to running out of write
        Message 3 of 10 , Nov 12, 2007
          David Given wrote:
          > On Sun, 2007-11-11 at 20:51 +0100, Martin Michlmayr wrote:
          > > - The first guide is for people running Linux on a flash device, such
          > > as a USB flash stick. Since flash only supports a limited number of
          > > writes, it is important to reduce the wear and tear on the underlying
          > > flash device. David's guide gives some practical advice of how to
          > > achieve this: http://www.cyrius.com/debian/nslu2/linux-on-flash.html
          >
          > Actually, I'm not sure that's entirely true any more. Flash has gotten a
          > *lot* better recently.
          >
          > Finding the rewrite tolerance for a modern cheapo flash card is a little
          > hard, but it seems to be about a million these days. Given that the card
          > itself does wear levelling, that means that you end up with 1'000'000 *
          > number of blocks worth of writes before you start running into trouble.
          > So, assuming a 32kB block size (based on nothing other than my knowledge
          > of flash chips), that's roughly 32 TB of writes per gigabyte.

          Yes. I have been using flash exclusively on everything that I own for
          nearly two years now with no failures that can be attributed to running
          out of write capacity. (One thumb drive did die of other causes; the
          moral of that incident might be to not buy cheap junk from Ebay.)

          Some time ago I proposed a flash drive lifespan survey so that we could
          get some hard data. This was not greeted with much enthusiasm, while
          FUD about flash still abounds. If anyone would like to pick up the
          baton, the page is still on the Wiki.

          Concerning the page that Martin linked to:

          - The page doesn't mention the disadvantages of any of the proposed
          changes. This mainly involves greater corruption in the event of a
          power failure or crash.

          - The suggestion to periodically "move your swap file to another part
          of the disk" seems to be ignorant of the idea of wear levelling.

          - Disabling syslog's MARK lines will save you one block-write every 20
          minutes, which is such a tiny amount as to be utterly useless.


          Regards,

          Phil.
        • Martin Michlmayr
          ... I do, as always, appreciate patches. ... -- Martin Michlmayr http://www.cyrius.com/
          Message 4 of 10 , Nov 12, 2007
            * Phil Endecott <spam_from_nslu2_linux@...> [2007-11-12 10:30]:
            > Concerning the page that Martin linked to:

            I do, as always, appreciate patches.

            > - The page doesn't mention the disadvantages of any of the proposed
            > changes. This mainly involves greater corruption in the event of a
            > power failure or crash.
            >
            > - The suggestion to periodically "move your swap file to another part
            > of the disk" seems to be ignorant of the idea of wear levelling.
            >
            > - Disabling syslog's MARK lines will save you one block-write every 20
            > minutes, which is such a tiny amount as to be utterly useless.
            > Phil.

            --
            Martin Michlmayr
            http://www.cyrius.com/
          • David Given
            On Mon, 2007-11-12 at 20:27 +0100, David Härdeman wrote: [...] ... You re the first person I ve *ever* met who actually has a flash device that s worn out...
            Message 5 of 10 , Nov 12, 2007
              On Mon, 2007-11-12 at 20:27 +0100, David Härdeman wrote:
              [...]
              > And finally, I *have* done a test about 1,5 years ago, using three
              > different fairly new flash keys that I had lying around. 512 byte sync
              > write to the same sector (not mounted, so not via a file system) once
              > every second for about ten days. Two of the flash keys showed no
              > problems (and one of them is in use today as a flash swap device), while
              > one started reporting write errors left and right after about three
              > days. Unsurprisingly, the cheapest one was the one that died.

              You're the first person I've *ever* met who actually has a flash device
              that's worn out...

              > The flash keys are improving, and improving fast, but saying "wear
              > leveling" like its a magic incantation is dangerous.

              Indeed it is. Nevertheless, I reckon it's now good enough to be usable
              (particularly as a lot of the progress has happened in the last couple
              of years). Two of your flash devices are still working, after all, even
              under heavy load... and given the price they are these days, I can
              afford to destroy devices until I find one that works. (I'm just setting
              up a cheapo 128MB key as swap, mostly to see what happens.)

              However, it's very interesting that the one you found that did fail
              failed so soon. I'd definitely consider that badly programmed. If there
              are still devices that bad around these days, I need to keep a careful
              eye out for problems --- if I start getting problems I'll chuck it and
              move back to real swap.



              PS. Please don't cc me if you're posting to the list --- I don't need
              multiple copies!

              --
              ┌─── dg@cowlark.com ───── http://www.cowlark.com ─────
              │ "I can handle myself. I've been in a fire fight. Well, I was in a
              │ fire.... Actually I was fired. From a fry cook opportunity." ---
              │ Firefly, _War Stories_
            • Martin Michlmayr
              Forwarded for David Härdeman who isn t subscribed at the moment: ... Wear leveling is no panacea. If there was a way to implement perfect flash wear leveling
              Message 6 of 10 , Nov 12, 2007
                Forwarded for David Härdeman who isn't subscribed at the moment:

                Phil Endecott wrote:
                > - The suggestion to periodically "move your swap file to another part
                > of the disk" seems to be ignorant of the idea of wear levelling.

                David Given wrote:
                > Actually, I'm not sure that's entirely true any more. Flash has gotten
                > a *lot* better recently.
                >
                > Finding the rewrite tolerance for a modern cheapo flash card is a
                > little hard, but it seems to be about a million these days. Given
                > that the card itself does wear levelling, that means that you end
                > up with 1'000'000 * number of blocks worth of writes before you start
                > running into trouble. So, assuming a 32kB block size (based on nothing
                > other than my knowledge of flash chips), that's roughly 32 TB of writes
                > per gigabyte.
                >
                > Of course, it's not that simple, because you only need to write once
                > to a block before it needs to be written, which means this should be
                > treated as a very rough guideline only. However, my NSLU2, which is
                > heavily overloaded and swaps more or less constantly, claims to write
                > at, on average, 1.5MB / minute. This means that a 1GB flash card
                > should run it for approximately 20 million minutes, which comes
                > out at about 40 years. A bigger card, of course, will last longer.

                Wear leveling is no panacea.

                If there was a way to implement perfect flash wear leveling without
                prohibitive cost (in additional storage, bandwidth, processing power,
                etc), the companies would be all over it.

                I'll give you one example of a common wear leveling implementation, and
                you'll see why its *not* perfect:

                The flash memory is divided into addressable blocks of size Y kB. N + X
                physical blocks are grouped together and addressable using N logical
                block addresses. The X additional physical blocks are regarded as
                unallocated. A table is also provided with N entries mapping
                logical <-> physical block addresses.

                When a block is written to, one of the X free blocks are selected
                instead and the table is updated so that the previously allocated block
                is marked as unallocated. If the write is partial, the rest of the data
                is copied over from the old to the new block.

                Common values are Y = 16kB, N = 1000, X = 24. If a filesystem writes 512
                bytes, you get an overhead of a factor of 32 as the entire block of 16kB
                is written (and even worse, imagine a 16kB synchronous write to the same
                block in 512 bytes increments => 32 writes of the same 16kB to flash).
                The worst case scenario is that the same block is written over and over
                again which would cycle through the currently allocated block and the 24
                possible replacements, giving an estimated life of 25 * <max_writes>.

                I've seen devices that have 10.000 as advertised <max_writes>, or 25.000
                writes in total. That is once per second for 7 hours, or once per second
                for about 3 days with a maximum write count of 100.000, or about a month
                with 1.000.000. Also, with bigger devices, the value of Y tends to
                increase, which actually increases the risk that a write ends up on the
                same block as the previous write.

                But that is only one example, I've tried to get info from some flash
                storage vendors on how they implement wear leveling and none were
                willing to provide it (or provided marketing fluff). What I have done on
                the other hand is to study their patent applications. A simple search on
                terms like "wear leveling" and "flash" gives about 30 - 60 applications
                (depending on how you count), pretty evenly distributed among the
                expected suspects. There are many, many, different approaches, and some
                of them are even less optimal (for example, by storing lots of internal
                bookkeeping data in flash as well with an unknown update rate). The mere
                fact that they are unwilling to explain the method used in their own
                products does not instill confidence. The fact that more efficient
                methods (might) require the payment of royalties and the low cost of the
                devices doesn't either.

                Now, if you do want to go into anecdotal evidence and conjecture, I'm
                pretty certain that there are devices which does not implement wear
                leveling at all (or so poorly that it is basically useless) no matter
                what they advertise (and I've seen others suggesting that on LKML as
                well). Also, by looking at the patent applications and what others have
                said, there are wear leveling algorithms that try to understand the
                structure of the filesystem written to the device...and guess what, they
                only take FAT into consideration (so in a best case scenario, the device
                realizes its not looking at a FAT filesystem, worst case, it believes it
                does and tries to "optimize" accordingly by e.g. preparing "unused"
                blocks in the background).

                And finally, I *have* done a test about 1,5 years ago, using three
                different fairly new flash keys that I had lying around. 512 byte sync
                write to the same sector (not mounted, so not via a file system) once
                every second for about ten days. Two of the flash keys showed no
                problems (and one of them is in use today as a flash swap device), while
                one started reporting write errors left and right after about three
                days. Unsurprisingly, the cheapest one was the one that died.

                The flash keys are improving, and improving fast, but saying "wear
                leveling" like its a magic incantation is dangerous.

                --
                David Härdeman

                --
                Martin Michlmayr
                http://www.cyrius.com/
              • cbm128
                ... hello, thanx for the really useful hints I know it might be more for the debian arm forum, but since the topic has been raised here ... how can it be
                Message 7 of 10 , Nov 15, 2007
                  > - The second guide gives a few tips and tricks that can be used to
                  > reduce the amount of RAM a system needs. This is particularly
                  > interesting to NSLU2 users since 32 MB of RAM is not a lot.
                  > http://www.cyrius.com/debian/nslu2/reducing-memory.html
                  >

                  hello,
                  thanx for the really useful hints

                  I know it might be more for the debian arm forum, but since the topic
                  has been raised here ...
                  how can it be possible that it takes almost 30 minutes to install a
                  package on my 32MB debian 4r01 nslu2?

                  I have just the bare minimum running on the system; unneeded kernel
                  modules and services like exim, rpc etc disabled, and around 14MB of
                  ram free.
                  Still when dpkg is run by apt-get it reach memory usages of more than
                  40MB with a total swap up to 40MB.

                  Is it normal? are there any other ways to perform package management
                  in less time?

                  I have seen mentions of using busybox but the version available has no
                  dpkg support

                  Thanks,

                  Max
                • Gordon Farquharson
                  ... Which package are you trying to install? I ve never seen dpkg or apt take that long. ... Is this for all packages? Gordon -- Gordon Farquharson GnuPG Key
                  Message 8 of 10 , Nov 15, 2007
                    On Nov 15, 2007 8:17 AM, cbm128 <cbm128@...> wrote:

                    > I know it might be more for the debian arm forum, but since the topic
                    > has been raised here ...
                    > how can it be possible that it takes almost 30 minutes to install a
                    > package on my 32MB debian 4r01 nslu2?

                    Which package are you trying to install? I've never seen dpkg or apt
                    take that long.

                    > Still when dpkg is run by apt-get it reach memory usages of more than
                    > 40MB with a total swap up to 40MB.

                    Is this for all packages?

                    Gordon

                    --
                    Gordon Farquharson
                    GnuPG Key ID: 32D6D676
                  • David Given
                    On Thu, 2007-11-15 at 16:09 -0700, Gordon Farquharson wrote: [...] ... He might be using aptitude; that s notorious for using lots of memory. On my system, it
                    Message 9 of 10 , Nov 15, 2007
                      On Thu, 2007-11-15 at 16:09 -0700, Gordon Farquharson wrote:
                      [...]
                      > Which package are you trying to install? I've never seen dpkg or apt
                      > take that long.

                      He might be using aptitude; that's notorious for using lots of memory.
                      On my system, it takes aptitude over five minutes simply to start up
                      (when using the graphical interface).

                      apt-get is considerably faster (although still rather painful to use
                      interactively).

                      --
                      ┌─── dg@cowlark.com ───── http://www.cowlark.com ─────

                      │ "The god of the Old Testament was actually a TRIBE OF RENEGADE SPACE
                      │ CANNIBALS." --- Robert McElwaine
                    • cbm128
                      ... I ve never user aptitude, I just tried using dselect (being used to it) but switched almost immediately to apt-get due to dselect not being responsive at
                      Message 10 of 10 , Nov 19, 2007
                        > He might be using aptitude; that's notorious for using lots of memory.
                        > On my system, it takes aptitude over five minutes simply to start up
                        > (when using the graphical interface).
                        >
                        > apt-get is considerably faster (although still rather painful to use
                        > interactively).
                        >

                        I've never user aptitude, I just tried using dselect (being used to
                        it) but switched almost immediately to apt-get due to dselect not
                        being responsive at all.

                        The problem was happening indipendently of the package being installed.
                        Now I cannot reproduce the error any longer because I had a problem
                        and had to reinstall from scratch, now the time required is acceptable
                        (some minutes), swap is still used but I does not bother me since it
                        is faster enough.

                        Thanks for the replies.
                      Your message has been successfully submitted and would be delivered to recipients shortly.