[Sugar-devel] Hello, was Re: Hack to get a USB/SD to autologin to only "Sugar-desktop on a stick". from a F12-alpha live CD

[David Farning]

I am currently at the hypothesis stage.

My hypothesis is that something is causing an excessive number of
reads/writes to a small portion of a USB memory stick.  My first guess
is that the problem is the interaction of _cheap_ usb chips/firmware
and the filesystem overlay.

The test are described at http://wiki.laptop.org/go/NAND_Testing .
Each test is an instance of Sugar running off an USB stick in qemu.

I am not sure how accurate these test are because of qemu and system
level caching.  At this point I am just running a hacked version of
the above test until the SoaS instance to fails.  Standard SoaS fails
within a few hours. Installing the SoaS overlay as an ext2 filesystem
has lasted about 10X time longer before I stopped the tests.

It is going to take me a while to understand what these tests mean (if
they mean anything) and if other qemu or system factors are screwing
up the results....

david

On Wed, Sep 9, 2009 at 3:39 PM, Martin Dengler<martin at martindengler.com> wrote:
> On Wed, Sep 09, 2009 at 03:21:50PM -0500, David Farning wrote:
>> Thanks for joining us Douglas.
>>
>> I would like to point out that there are two separate yet interlinked
>> issues at hand:
>> 1. Easy and fast install.
>> 2. Running OS natively on removable solid state media.
>
> What do you mean by "running OS natively"?
>
>>
>> Douglas' Liveos solved the first issue.  It is very fast and easy to
>> install an OS to a hard drive by dd'ing the contents of the overlay to
>> the hard drive.
>>
>> I am suggesting that ease of installation to another medium is not
>> longer the primary usecase for SoaS.
>
> Caroline continues to ask for easy ways to duplicate a stick.
>
>> The primary use case is now running Sugar and the underlying OS as
>> natively as possible on the removable solid state media.  The primary
>> goals are now reliability and speed.
>
> What does "as natively as possible" mean?
>
>> The issue is not that overlays are bad/good or real file systems.  The
>> issue is, can SoaS improve stick reliable  and speed by eliminating
>> the overlays and writing the _contents_ of the overlay directly onto
>> the solid state device
>
> Is what you're saying that it's easier to corrupt a bit on the overlay
> than it is to corrupt a bit on a non-overlay fs?
>
>> using a file systems which is aware of the design characteristics of
>> current generations of USB keys.
>
> Please clarify what you mean.
>
>> I have been conducting some very initial tests using WAD's SD card
>> test tools.
>
> Where can these be found?
>
>> #1. Standard SOAS.
>> #2. Install the contents of the SoaS overlay to a usb key using
>> #   ext2.
>
> Meaning what exactly?
>
>> I am just running various methods of installing soas on USB sticks in
>> qemu directly from usb sticks using
>>
>> qemu  -hda /dev/sd*
>>
>> My initial runs using the cheapest drives I could find at best buy
>> indicate that #2 has at least 10X the lifetime as #1.
>
> What are the units in which you're measuring "lifetime"?
>
>> david
>
> Martin
>