I have just started experimenting with Knoppix on SSD drive, and in many ways, it seems like an ideal match. Using a 240GB drive, I can set up a couple of 16 GB partitions for different Knoppix versions, plus a 50GB Win7 partition, and still have space for a /store partition for virtual machines, development work etc.

Remastering goes very fast this way (ca 5 min for 12GB system copy), but the most important practical benefit was the speed of virtual machines (under VMware workstation 8 ). Suddenly, it became quite fine to surf in a Knoppix VM under Knoppix.

Regardless of all assurances, there are some concerns about SSD: 25 micron NANDs may have as little as 3000 write cycles/cell. And though smart controllers should be able to even out the write load, we may, for axample, have error situations where they are not able to cope fully. Last year's kernel 2.37-bug, for example, locked up one of the cores in certain configurations in a loop (machine was still usable with the other cores..), and it made my externally mounted SSD run rather hot. As long as it's only reading, it should in principle be fine - but it is possible to thrash it.

Durability may also be an issue, not all SSD drives are created equal.

So - in ordinary use, it may be advisable to minimize disk writing also with SSD. (It is of course even more important when running from USB sticks.) One simple scheme is to use knoppix-data.img mostly as a backup-and-restore volume, and use /ramdisk as the ordinary "persistent" store.

Content can be read into /ramdisk on boot, and (eventually) written back on shutdown, or when needed. It could also be scheduled as a cron job, but that would not by itself ensure full updating.

One of the reasons I have never thought much about such a solution, is that my persistent store has often been well-filled, 1-3 GB, and that's not very suitable for ramdisk handling. And I try to stick with just one KNOPPIX compressed image for ordinary use. With a SSD and squashfs, remastering is, however, so fast and simple that there is not much sense in having much data in the persistent store for a long time.

For ordinary backing up etc, it is of course often easier to use something smaller than knoppix-data.img, but switching seamlessly between noimage and persistent use may be important, for example when running same Knoppix on different machines or under different RAM requirements.

Adding a cheatcode like norestore could direct knoppix.sh to not initialize /ramdisk with the contents of knoppix-data.img on boot, and not write it automatically back on shutdown. If knoppix-data.img is written under norestore, it should probably be completely rewritten, as we could otherwise create inconsistencies.

With the emergence of cheap and fast USB3 sticks, running Knoppix off USB media has become a useful option, and this method could make it even simpler and safer. And if persistent store is not updated, the potential loss is limited to the actual session. The most important things to keep are of course program installs and updates, and good practice would be to update persistent store after each such modification.