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(a)redhat.com
>>
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
>
>
>
>
--
Fedora-livecd-list mailing list
Fedora-livecd-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
--
Thanks
Ashok Shankar Das
RedHat, Pune
+91-9373695832