[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

Douglas McClendon dmc.sugar at filteredperception.org
Thu Sep 10 06:11:46 EDT 2009


David Farning wrote:
> 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.

Sounds extremely plausible to me.

> 
> 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 skimmed and grepped for 'overlay'.  Not seeing it I presume this is all 
installed systems, and not LiveOS+overlay.  Though the proximity of this to 
your above hypothesis including overlays leaves me uncertain.

Basically if these tests are against installed systems, I really don't have 
anything useful to add.  But if this involves LiveOS style boot with overlay, 
then I still don't have much to add other than I assume/hope your tests don't 
trigger overlay exhaustion and confuse that with media error.

-dmc



> 
> 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
>>



More information about the Sugar-devel mailing list