[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Draft proposal for debian-custom

Fabian Franz <FabianFranz@gmx.de> writes:

> Am Donnerstag, 3. Juni 2004 18:19 schrieb Alex de Landgraaf:
>> Quoting Free Ekanayaka <free@agnula.org>:
>> > I didn't understand whether you are going to work with debix or what..
>> >
>> > I didn't  have time to try  debix, but it looks  very promising  to me
>> > comparing with Knoppix and Morphix, especially because  it seems to be
>> > fully Debian compliant.
>> I too haven't tried debix myself, but a (soon-to-be?) DD did check it out a
>> few days ago and found it rather... broken. Anyway, the use of DV/LVM2 for
>> overlaying is very cool indeed, and I'd love to see if this could be used
>> for our modules instead of the existing hacks.
> No, it cannot in my humble opinion. There is a design issue, which cannot be 
> overcome too easily and you loose the possibility to speed-optimize (you have 
> to use ext3 to allow overlay to work :-/). Also as far as I can see there can 
> just be a writable snapshot so much less, then what you do with morphix right 
> now.

Device mapper works on the block device level. The filesystem used is
irelevant and a journaling filesystem is not realy optimal because it
moves the journal into the ramdisk almost emidiatly.

> Problem for example are: 
> - Kernel crashes, when space exceeds snapshot ...

Can't reproduce that. That would be a kernel bug and has to be fixed.

> - df is not updated (not even possible, as block-layer does know nothing about 
> filesystem layer)

With tmpfs the df is updated as the loopback file of the mirror grows.

A problem is that the fs never shrinks when space is freed. Thats the
cost of 0 changes.


Reply to: