fusecompress on knoppix-data.img?

[dinosoep]

I was looking around and found fusecompress, does anyone has experience with this?
Later this evening or tomorrow I'll try to mnt my knoppix-data.img with fusecompress and see how it works out.

are there better alternatives out there?

[dinosoep]

and another question (as I'm worried about my usb lifespan) can I mount knoppix-data.img read only at startup with /ramdisk mount on top of unionfs and when I feel the need "flush" the changes by remounting knoppix-data.img read-write and syncing the changes?
and do this at shutdown?
if so, could one help me a bit with this? I'm not very smart

[Capricorny]

I don't know anything about fusecompress, but I think the USB wear issue is significant. Entries in the /home directory are updated all the time. It seems that we may mount /home separately with the present standard setup, but normally, /var is also frequently updated. So at least those two, plus eventually parts of /etc should go somewhere wear-proof. For instance on a ramdisk that is initiatied at boot and written to persistent store at shutdown.

It should not be too hard to achieve this, but as I have no recent experience with ramdisks, I will only point to the possibility.

From 6.4.4 cheatcodes, we have the following choices on boot:

 
### Configuration / Persistent image ###
knoppix nonetworkmanager            Don't start network manager
knoppix home=/dev/sda1/knoppix.img  Mount loopback file for overlay
knoppix toram                       Copy to RAM and run from there
knoppix tohd=/dev/sda1              Copy to Harddisk and run from there
knoppix fromhd=/dev/sda1            Boot from previously copied CD-Image
knoppix bootfrom=/dev/sda1/KNX.iso  Access image, boot from ISO-Image. ***)
knoppix knoppix_dir=KNOPPIX         Directory to search for on the CD. 
knoppix knoppix_name=KNOPPIX        Cloop-File to search for on the CD.
knoppix noswap                      Don't use existing swap partitions
knoppix forensic                    Don't use swap and mount read-only
knoppix secure                      Disable root access
knoppix noimage                     Do NOT use persistent image

Maybe we could have a new cheatcode "wearproof", that copies frequently updated directories like /home and /var to ramdisk and runs from there?

[dinosoep]

Exactly what I'm going to try.
I think that could be achieved by mounting knoppix-data.img read only, create a new ramdisk about the same size as knoppix-data.img and mount it read-write over /KNOPPIX-DATA. Then everytime you run a certain script or shutdown knoppix-data.img get's remounted read-write and all changes are copied over to knoppix-data.img...

To bad I'm not good enough
First I'm going to try and make fusecompress work, then I'll play around with the ramdisk stuff

[Capricorny]

Exactly what I'm going to try.
I think that could be achieved by mounting knoppix-data.img read only, create a new ramdisk about the same size as knoppix-data.img and mount it read-write over /KNOPPIX-DATA.

You surely describe the easy way, but my knoppix-data.img is 4GB...
So in my case, there must be some extracting and updating of selected directories involved.

[dinosoep]

with unionfs only the changes you try to make to the read-only filesystem will be stored on the ramdisk, So there will be no extraction of files on from knoppix-data.img to the ramdisk unless you edit them.

[Capricorny]

with unionfs only the changes you try to make to the read-only filesystem will be stored on the ramdisk, So there will be no extraction of files on from knoppix-data.img to the ramdisk unless you edit them.

In that case, it would be enough to setup a, say, 200MB ramdisk to accomodate the changes made during an ordinary session? Not knowing UNIONFS, I thought the union process could not be iterated beyond the cloop and persistent image, but it can? As for knoppix-data.img, a simple scheme could then be to have two images mounted alternatingly, so at shutdown, the actual UNIONFS directories are written to the backup image, which is then used for booting the next time? Then we would stay entirely within live UNIONFS during the whole process, like we are in remastering.

[dinosoep]

It's going great, at the moment I have a fully functional system forgetting everything at shutdown
No really, I managed to make it create a ramdisk (currently of 4 gigs max, I know it's ridiculous) and make knoppix-data.img read-only
There is a script out there (I forgot the name) that can sync that ramdisk to knoppix-data.img, I just need to put it in a cron job.

Having started up chromium, a couple of tabs, conky,... I'm using 219 mb of ram with only 26 mb used by the ramdisk
i'll keep everyone informed

[Capricorny]

...I managed to make it create a ramdisk (currently of 4 gigs max, I know it's ridiculous) and make knoppix-data.img read-only
There is a script out there (I forgot the name) that can sync that ramdisk to knoppix-data.img, I just need to put it in a cron job.

I have had a quick look at some of the unionfs documentation.
http://www.fsl.cs.sunysb.edu/project-unionfs.html. In particular the presentation from the 2006 Ottawa symposium.
It seems clear that mounting knoppix-data.img read-only is quite OK, Only the highest priority branch must be mounted rw to create a writable system, and it only has to be big enough to accomodate the updates/additions to the file system. But I wonder what kind of mounting gymnastics must be performed if the persistent, read-only-mounted image is to be updated in a cronjob on a running system?

[dinosoep]

Knoppix uses aufs2, this is like a more improved version of unionfs (according to kl522 I don't know enough to compare both of them).
You can specify branches and mount them over eachother and also specify the operations that can be performed on them WITHIN the unionfs space.
So say I have a writeable directory A and another B, then I can mount A over B and say that A is read-only while in fact it is read-write.

This way I can make it save all unionfs changes to the ramdisk and also run another script to bypass the unionfs read-only limitation and that script exists, it's called "aubrsync".

This all sounded too good to be true and in fact it is there is one catch and that is that aufs-tools need to be installed and be the same version as the one that was used to patch the kernel. Too bad I have no idea what that is...

I am currently trying to compile the newest version without succes, I'll continue my quest tomorrow