[Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only

[Douglas McClendon]

ashok shankar das wrote:
> Douglas McClendon wrote:
> 
>> Jeremy Katz wrote:
>>
>>> On Mon, 2007-08-20 at 14:10 -0500, Douglas McClendon wrote:
>>
>>
>>>> Well, the way ubuntu is trying to do it of course, is with unionfs 
>>>> (since of course they use unionfs rather than dm-snapshot to get cow 
>>>> in the first place).
>>>>
>>>> And as such, unionfs can provide just as persistful an 
>>>> implementation as the direction I've been going.  In both cases you 
>>>> can think of the persistence as another embedded layer in the total 
>>>> root filesystem.
>>>
>>>
>>> It's been quite a while since I looked at unionfs, but I vaguely
>>> remember that it was more subtree overlays.  I guess you could perhaps
>>> do a subtree of /.  But even so, I don't know that supporting multiple
>>> ways of achieving the same goal is really where we want to go.  But it's
>>> somewhat academic at the moment, so probably not much discussion needed.
>>
>>
>>
>> I'm not sure if there is some meaning of subtree that is different 
>> than subdir.  But the way most livecds work, is by having a big 
>> squashfs with your root filesystem (all of it, not seperated into 
>> subdirs or anything), and then having a tmpfs, and then using unionfs 
>> to make the tmpfs act as a layer over the squashfs, and then doing 
>> pivotroot to that  single unionfs filesystem.
>>
>> Kadischi used the method that was predominant before that unionfs 
>> method, which was to have many subdirs (/usr, /opt) be read only, and 
>> then have some subdirs (/tmp, /var, ...) be read only.  Perhaps using 
>> bindmounting or symlinks to handle some specific sub-subdirs.
>>
>> Back to unionfs-  The major disadvantage of unionfs is that it is not 
>> 'perfect' as a real rootfs (why AFAIK fedora/rh refused to merge it). 
>> I.e. there are some known bugs, which knoppix and ubuntu just take as 
>> an acceptable tradeoff.
>>
> the problem is in symlinks(unionfs).  incase of devmaper this problem is 
> not there. But there is another issue. The snapshot size. The method I 
> follow is ofcourse Devmaper. But i tryed with fuse and funionfs but not 
> tested vigourously.

Yes, I just ran across a page describing how ubuntu actually used to use 
devicemapper snapshot, but switched to unionfs, because they said it was 
faster and more flexible (and the overlay memory usage not decreasing 
when cow created files get deleted).

As mentioned, it might be interesting work (for some day far from 
today), to see if you could get rm to zero out files, and then have them 
not take up space in the overlay device afterwords.  I notice from man 
chattr(and shred) there is already some work on the zero-out parts, and 
perhaps dm-snapshot is already smart enough to detect that the newly 
changed overlay blocks match the base blocks (0s in both cases), and 
free the associated memory.

It would be nice however if there was a bulletproof unionfs 
implementation though...  that was as reliable for the rootfs as say, 
LVM has proven to be.

-dmc


> 
>> The major advantage of unionfs, for the specific persistence topic at 
>> hand, is that when you delete a file from the COW rootfs, in unionfs, 
>> the memory is actually freed.  Whereas for the dm-snapshot 
>> implementation of persistence, that is not the case.
>>
>> This may be acceptible.  There may be workarounds for it (using shred 
>> to delete files into 0's, and then resparsifying the persistence 
>> overlay?)
>>
>> Anyway...  yes, academic.
>>
>> And unionfs can't get rebootless installation (bwa ha ha....)
>>
>> -dmc
>>
>>
>> -- 
>> Fedora-livecd-list mailing list
>> Fedora-livecd-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-livecd-list
> 
> 
>