[SoaS] [Sugar-devel] SOAS 2 problems

[Bernie Innocenti]

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


> Now, the closest thing livecd-tools has to a maintainer at the moment is 
> I think someone who considers me an obnoxious <expletive deleted> due to 
> a prior exchange we had about a 1 line reversion of a reversion to the 
> code.  Of course the feeling is mutual, but hopefully it won't interfere 
> with the adoption of the above solution/workaround to the problem you 
> described.

Ah, the joys of social interaction between engineers, where technical
disagreement can quickly degenerate into personal issues! Fear, anger,
hate... the dark side are they ;-)

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/