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

[ashok shankar das]

Douglas McClendon wrote:

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

I agree with your views. And The LVM stuffs are really nice, but why not 
experiment with new things?
That is why if sombody can make *unionfs/funionfs* rock solid then the 
livecd/persistent issue would be solved.
Even i could dream of a diskless persistent handheld device too ;)

>
> -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
>>
>>
>>
>>
>
> -- 
> Fedora-livecd-list mailing list
> Fedora-livecd-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-livecd-list



-- 
Thanks
Ashok Shankar Das
RedHat, Pune
+91-9373695832