[SoaS] [Sugar-devel] SOAS 2 problems

[Douglas McClendon]

On 01/25/2010 08:19 AM, Bernie Innocenti wrote:
> On Sun, 2010-01-24 at 22:08 -0700, Douglas McClendon wrote:
>> Bernie, please file a bug with fedora against livecd-tools.  I will
>> craft a fix that at boot time, upon detecting a filled overlay on usb
>> storage, automatically adds a second overlay based in ram (as the livecd
>> or nonpersistent liveusb do normally).
>>
>> In this way, you should always be able to boot.  I will add a text
>> message displayed at the time, telling the user that the overlay is
>> full, and that new changes will only be temporarily written to memory,
>> and that they should copy any needed data to another device, and then
>> reset their overlay at next boot by adding the kernel parameter
>> 'reset_overlay' when they next boot.
>
> I'm glad you're willing to solve the issue, but the proposed solution
> seems too kludgy to be feasible. It brings even more corner cases and
> failure modes, such as: what if the USB stick is full? what if the user
> carelessly lets the second overlay fill up?

I don't think you understand the infrastructure yet.  The USB stick 
being full isn't an issue, because the new overlay is in RAM only.  The 
only way the user would fill up the second in RAM one, is the same way 
they would fill it up while using a nonpersistent liveusb or livecd. 
I.e. using it to the point that the ram available for it (by default 
half the ram available) fills up.  Clearly you didn't read what I said 
enough to understand the whole warning to the user about how this was a 
rescue mode to recover their data and reset the overlay.  Nothing more, 
nothing less.

Either file a bug (and cc me) if you want it fixed, or not if you don't.

>
> I agree that I've been too quick in calling what liveusb is doing
> "wrong". There are certainly some use-cases where it makes sense to use
> a compressed filesystem with a writable overlay in order to reduce the
> image size and reduce data reads. (although, in my tests, the direct
> ext3 filesystem beats squashfs by a few seconds on regular 4GB USB
> sticks).
>
> All considered, I'm convinced that this entire squashfs + dm-snap
> approach is borked beyond any possibility of repair. If we really had to
> use compression, I'd go for a unionfs based approach instead. The
> downside is that, while there are plenty of unionfs implementations
> around for Linux, none of which has ever made it into the vanilla kernel
> due to unsolvable design issues. Since Fedora is (understandably)
> reluctant to rely on large patches not in Linus' tree, we're kind of
> stuck.

Please, stop criticizing, and start coding.  If you provide a better 
implementation, the world will thank you.  If all you can do is 
criticize without improving the code, to the point of alienating 
developers who can fix the legitimate problems you mention, then please 
shut up.

It's been fun.  But I don't have time for soas list anymore.  Please 
direct all further questions, comments, criticisms, bugs, directly to me 
via email.

Good luck...

-dmc