well, you could use a kind of "persistence" that is maybe a hybrid between a HDD install and a LiveCD/USB install.

I have Slackware installed into a smallish partition, and a full Slackware install is too big, so I made a kind of hybrid system wherein the whole /usr is compressed into a squashfs filesystem which uses xz compression and requires also a aufs3 patched kernel.

the system is completely persistent as even with a poweroutage there is a read/write folder where any changes made to /usr are gathered. on boot up it decompresses the read-only usr.sqfs and then reads from the read/write folder and syncs the two, the read-write taking precedence.
yes, it needs to be re-compressed whenever you want any changes permanent but it works great.
usr uncompressed is 4.1GB and as a compressed squashfs is 1.5GB.

heres my /etc/fstab

there are other tricks you can do with aufs3 and squashfs like maybe making just a firefox module that is read-only and lives in ram, never writing to HDD or whatever.
I also make a super small Slackware -current 200mb livecd/usb that is persistent and whole thing does copy2ram ala Slax.
dont know if any of that applies but if it does or you want to try it I can help

see here also, though mine is kernel 3.1.4 and aufs3

https://wiki.archlinux.org/index.php...ng_Performance

http://linux.startcom.org/HOWTO/Squa...gandusing.html

http://elinux.org/Squash_FS_Howto

@snowpine
what I ment by "do not impact performance very much" is that the syncing after system updates, config changes etc. does surely impact performance remarkably for that specific moment. But it occurs so rarely that this is acceptable. And I always can postpone system upgrades until the PC is not currently recording TV shows. I should have written "overall performance" ...

Writes on the root filesystm are rare, but as soon as I use the PC interactively, reads on root aren't rare any more. Everytime I start a program or open a file, I have to wait.

I am pretty sure it's because

• the much higher I/O amount on the video partition has kicked all blocks of the root partition out of the disk cache (what absolutely makes sense from the overall system point of view, but degrades the user experience from the interactive user's point of view)
• the disk's heads are (most probably) somewhere on the video partition, causing additional seeks for reads on root

Is that enough analysis of the bottleneck ?

These two things are what I want to workaround.
Either by influencing the disk cache (I learned in this thread that's impossible)
or by decoupling the root and video partitions.

As my hard requirement is not to add another harddisk, the ramdisk seems worth a try for simulating a very fast second disk (I know I wrote that before).

Gernal note:
The PC (and especially the harddisk) is not operating on razor's edge. It just "feels" uncomfortably slow to the interactive user.

This project is a partially about improving the user experience (which has a positive influence on the the WAF, so it's absolutely not unimportant) and partially about finding out if it is doable.

@linus72
Hey, cool, this is something I will also have a look at.

Sadly, my boss asked me today to work overtime for the rest of the year. So my work on this project will be much slower than I have planned as I will have very few free time from now on ...


[Edit]
WAF = Woman Acceptance Factor
[/Edit]

If it's simply a matter of a "snappy" user interface then have you experimented with: disabling desktop effects, using a "lightweight" DE like LXDE, optimizing graphics drivers/swappiness/startup services, etc?

The desktop is as minimalistic as it can be: OpenBox.

Well, if you want to run your system from RAM this is the approach that works on Slackware. Since Ubuntu uses a different init-system I don't know if that will work on Ubuntu.