[SoaS] SoaS filesystems was: Re: Sugar on a Stick Meeting on Monday at 1900 UTC

[Frederick Grose]

On Mon, Jul 19, 2010 at 6:13 PM, pbrobinson at gmail.com
<pbrobinson at gmail.com>wrote:

> On Mon, Jul 19, 2010 at 10:48 PM, Frederick Grose <fgrose at gmail.com>
> wrote:
> > On Mon, Jul 19, 2010 at 5:37 PM, Walter Bender <walter.bender at gmail.com>
> > wrote:
> >>
> >> On Mon, Jul 19, 2010 at 1:06 PM, Frederick Grose <fgrose at gmail.com>
> wrote:
> >> > On Mon, Jul 19, 2010 at 10:41 AM, Mel Chua <mel at melchua.com> wrote:
> >> >>
> >> >> I'm going to have to miss today's meeting, but as an update on my
> task
> >> >> from last week: http://bugs.sugarlabs.org/ticket/1798#comment:22
> >> >
> >> >
> >> > See this comment added
> >> > to http://bugs.sugarlabs.org/ticket/1798#comment:23 :
> >> >
> >> > School-based deployments may want to take advantage of the persistent
> >> > /home/
> >> > directory installation instead of the persistent OS overlay. The
> >> > persistent
> >> > home folder is not a write-once, ever-diminishing storage space.
> >> >
> >> > For consistency and stability reasons, the school may want to leave
> out
> >> > the
> >> > persistent OS overlay (using a temporary overlay on each boot) and
> just
> >> > use
> >> > the persistent /home/ directories to save the Learners' Journals and
> >> > settings.
> >> >
> >> > If a school-wide system change were desired, the Sticks could be
> >> > upgraded
> >> > with a simple exchange of the /LiveOS/squashfs.img file in the base
> file
> >> > system of each device or stick, perhaps, even triggered by the School
> >> > Server.
> >>
> >>
> >>
> >> {...}
> >>
> >>
> >>
> >> if the size of the image changes
> >> dramatically, are there any issues regarding how space may have been
> >> allocated?
> >
> > Yes, I imagine that if all free space were allocated to the home.img file
> > and a new, larger squashfs.img needed to fit on the disc, it would fail.
> >
> >>
> >> {...}
> >
> >
> >>
> >> > storage space optimization is discussed on this
> >> > page,  http://wiki.sugarlabs.org/go/LiveOS_image.
> >
> > On that page, there are some reasons suggested for leaving some free
> space
> > outside of the LiveOS installation.
>
> We're looking to have an option added to the liveusb-creator to select
> an option "Use entire stick for image" (or something similar) which
> would then get rid of the sqashfs all together and install the ext3
> partition straight to the usb stick so there's no issues with corrupt
> overlays and other related issues as it will be a plain filesystem
> straight onto a usb stick so there'll be no weird fu in between.
>
> Cheers,
> Peter


That is great for those with sufficient storage space.  There are some
compromises that suggest to me that SoaS should continue to fully support
LiveOS installations even if we choose to support a non-Live installation.

First is file space:

Using the --skipcompress option in the livecd-iso-to-disk installation
script results in a pristine installation that consumed 1.49 GB on disc, and
requires reformatting the USB/SD device to ext234. (I was testing on an
ext2-formatted disc in VirtualBox.)

With a fat32 formatted disc, the pristine image consumed 0.481 GB on disc.

On a 2-GB stick,  1.5 GB of space could be available for Sugar Activities or
other content such as textbooks with a LiveOS installation vs 0.5 for the
non-Live installation.

In the future, we hope to install SoaS onto smart phones and
other pocket-able devices where small images sizes will be even more
important.

Second, related to file space, is the speed of installation, replication,
and system sharing:

Installation onto the fat32 disc took 2:12 minutes:seconds on VirtualBox vs.
5:06 for the ext2 disc.  The smaller LiveOS image makes system installation,
backups, sharing quicker.

Third is reliability:

For non-specific USB/SD devices, the OLPC engineers recommend that one keep
the factory formatting,
see http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device

One may say that unexpected crashing from a overfilled persistent overlay is
a reliability problem.  Re-examining the failure report in
http://bugs.sugarlabs.org/ticket/1798#comment:18, the worst failure reported
suggests that in a classroom setting, the LiveOS installations worked
*reliably* for several months before the overlay filled up.  It seems,
rather, that there was insufficient understanding of the system limitations
and how to work with them.  I would be upset too, if a mountain highway
suddenly, and without warning, changed from 2 to 1 lane right at the hairpin
turn of an outer switchback and I was in the inner lane.

If one chooses to use a LiveOS persistent overlay, its consumption can be
easily monitored, and a Journal backup and restore scheduled around a system
refresh.  It is probably even be more reliable to install without an
operating system overlay, and use the volatile one created on each boot from
the read-only filesystem.

Fourth is versatility:

Not having the device's default filesystem format makes the device less
versatile for other applications and systems outside of the Sugar
environment.  One would have a much harder time sharing files with
Windows-based computers, for example.

The greater storage capacity made available with the LiveOS, allowing one to
use more of the disc free space for Activities and content, is really a
versatility compromise.

Quicker installation and sharing and the capability to install on more
devices also promotes greater adoption. That could be classified as a
versatility advantage as well.

Easier customization of images has been developed for LiveOS installations
with http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Sugar_Clone. This
provides versatility that teachers and administrators have requested and
benefits many more.

Thank you for considering these ideas!           --Fred
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/soas/attachments/20100719/4bb0a3cb/attachment-0001.htm