question about Knoppix flash disk write cycles

[nopics]

Hello All,

I have a question about Knoppix flash disk write cycles.

Considering the limited write cycles a usb stick can survive, I started with Puppy.
I installed Puppy on my USB stick and worked with it for a while.
Puppy gives the user complete control over the write cycle to the usb stick.
The user can manually trigger an update to the usb stick by clicking on a dedicated
icon on the desktop. Updates/changes are also written to the usb stick during shutdown.

User initiated write cycles are small in numbers and practically will bever reach
the usb flashdisk limit, but a mechanized (program initiated) write cycle can reach that
limit in few minutes.

I was not able to activate the encryption on Puppy, so I switched to Knoppix.
I installed Knoppix on my usb stick using "unetbootin", I then created an encrypted
persistent file, and I am working with it happily ever after.

However, Knoppix does not give a direct control over the usb write cycles as Puppy.
I don't know when/if Knoppix writes to the usb stick.
I know the "toram" cheat code will cause Knoppix to load itself to the RAM
and work from there, but what about programs that are running from the persistent file ?
Can such programs write to the persistent file back and forth ?
Is there a tool to show the user (me) when exactly does Knoppix writes to the usb stick ?
Could it be that I am actually killing my usb by runing Knoppix from it ?

Thanks for any help,

nopics.

[Capricorny]

If you search this forum for the "noimage" cheatcode, you may find some reflections on this theme. It is a principally important problem, but one reason why it doesn't seem to have attracted so much attention/action on Knoppix, is that disk writes to persistent store in practice don't happen all that often when there is an ample supply of RAM to use as cache.

There is really no principal difference between programs in the cloop and programs installed later when it comes to disk writes when a persistent store is in use, and whenever you update a program in the cloop, the new version is stored in the persistent store.

If you keep on issuing sync commands all the time, you force writing, but in general, disk writes may be fewer than you think, and because this is largely kernel stuff, nobody may have the exact answer about when Knoppix writes to disk.

I would also like to point out that the effective number of writes to a flash location is a random variable with a variance larger than we like (and the vendors tend to admit) So you are actually killing your usb by using it for anything that repeatedly writes to it. It just goes on so slowly that most won't notice, but every now and then the problem surfaces.

[Blacksimon]

Take a look at these references, I hope you can be useful:

- http://bernaerts.dyndns.org/linux/53...-compact-flash
- http://linux-howto-guide.blogspot.co...ite-speed.html
- http://blog.smartlogicsolutions.com/...m-performance/
- http://andyduffell.com/techblog/?p=852
- http://web.archive.org/web/200903090...ase-block-size
- http://cptl.org/wp/index.php/2010/03...ives-in-linux/
- http://www.styryx.com/en/computers/o...n-to-usb-flash
- https://wiki.archlinux.org/index.php/Solid_State_Drives
- http://blog.nuclex-games.com/2009/12...-ssd-on-linux/

[utu]

@ nopics
FWIW, my experience:
I use a small Knoppix LiveUSB exclusively and have for several years.
I don't know of any instance where I've run into a 'wear problem'.
On the other hand, I don't know what to look-for.

You might start to worry in earnest about the 'experimental' reiserfs
partition for KNOPPIX-DATA in Knoppix 7.0.5 LiveUSB. This is a journalled fs.
This alone 'ups the ante' on read-write-persistence.

@ anyone
For my own purposes, I cloop compress persistence files occasionally
and overlay these _read-only_ files alongside KNOPPIX in
/mnt-system/KNOPPIX/. This minimizes the need for additional persistence.
You can think of this as using ro-persistence and rw-persistence.

If I worried about write-wear, which I don't, I might also consider running
the noimage cheatcode most of the time.

I don't know how, or why, to worry about write-wear unless there is some
practical, quantitative measure to guage what's going on.

@ blacksimon
I really appreciate the reference list.

[Capricorny]

I also appreciate the reference list, blacksimon!
But reading through much of it, I only got my impression about the noimage approach confirmed. That will use the adaptations already built into Knoppix in an optimal way, I think. And people shy of remastering, can use utu's overlay approach to minimize persistent store space. (Actually, overlays+occasional remasterings might be a very good scheme.)
My own motive for working with this now isn't so much media wear as system robustness and efficiency. Media writes is the most costly, in terms of time and resources, and least predictable kind of operation I perform running Knoppix, so having a way to control them would greatly facilitate flexibility. Like running Knoppix off the micro sd card in my mobile phone (which worked well last time I tried, but a bit too slow writes then..)

[utu]

Is there a tool to show the user (me) when exactly does Knoppix writes to the usb stick ?
nopics.

You might do an audit of your own situation as a start.
For example, here's mine & my estimate of what it might mean
.

Here's an audit of my current 'cd-size' Knoppix 7.0.5 LiveUSB:

knoppix@Microknoppix:~$ df -h -T
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/sdb1      vfat     1015M  834M  181M  83% /mnt-system
tmpfs          tmpfs     2.8G     0  2.8G   0% /ramdisk
/dev/cloop     iso9660   1.9G  1.9G     0 100% /KNOPPIX      (Klaus K's r/o part )
/dev/cloop1    iso9660   333M  333M     0 100% /KNOPPIX1     ( my  own  r/o stuff)
/dev/sdb2      reiserfs  6.5G  208M  6.3G   4% /KNOPPIX-DATA ( my  own  r/w stuff)
unionfs        aufs      6.5G  208M  6.3G   4% /UNIONFS
unionfs        aufs      6.5G  208M  6.3G   4% /usr
unionfs        aufs      6.5G  208M  6.3G   4% /home
tmpfs          tmpfs      10M   60K   10M   1% /UNIONFS/var/run
tmpfs          tmpfs      20M  2.8M   18M  14% /run
tmpfs          tmpfs      10M     0   10M   0% /UNIONFS/var/lock
tmpfs          tmpfs     100M  228K  100M   1% /UNIONFS/var/log
tmpfs          tmpfs     2.0G  8.0K  2.0G   1% /tmp
udev           tmpfs      20M  4.0K   20M   1% /dev
tmpfs          tmpfs     2.0G     0  2.0G   0% /dev/shm

I think this can be interpreted as follows:

1. ramdisk       is rarely used, if ever.
2. tmpfs         I assume is all on ram.
3. /KNOPPIX      1.9G on ram comes from read-only /mnt-system/KNOPPIX/KNOPPIX  which is only 690M.
4. /KNOPPIX1     333M on ram comes from read-only /mnt-system/KNOPPIX/KNOPPIX1 which is only 118M.
5. /KNOPPIX-DATA reiserfs file is read-write & journalled, but photos account for 122M.

If photos were off-loaded, net reiserfs read-write would be restricted to about 90M,
but this is journalled, and that may be crucial to the write-wear situation.

[utu]

running Knoppix off the micro sd card in my mobile phone

.
I'm sharing my old Knoppix SD-cards now with my Panasonic point-and-shoot camera.
Hadn't thought about booting it up.;D