[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
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.
> 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....
> 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"?
More information about the Sugar-devel