Bao C. Ha wrote: > What I did in the article is for the OpenBrick-E. The OpenBrick-E > has 256M RAM in the default configuration, compared to the 128M > RAM OpenBrick. My next step would be to uncompress the cloop- > based filesystem and mount its entirety on the tempfs. Next, I > would be able to upgrade it on the fly. The only limit is the > size of the ramdisk, which is 256M for the OpenBrick-E. Then, > I just have to compress it again into the a clooped filesystem and > to store it on the compactflash.
Yeah that'd work ok. I thought about doing something similar with my hard disk as the scratch medium. > I do have a long to-do list, before it will be ready to be packaged. > Personally, I don't think it is safe to mount the compactflash as > the "live" root filesystem. It is not designed to have that many > write-cycles as a regular hard disk. So, even with a larger size > compactflash, what we are doing will still be valuable contributions. That's why I keep my whole root filesystem mounted read-only. My compact flash is only written to on clean shutdowns (rare..) when I rsync /var/log and other persistent state back to it, and when I upgrade or do some sysadmin task. I suspect this in fact will tend to wear out the flash less overall than your technique of blowing in an entire completly different compressed image for each change. Not that I worry about wearing out a cheap 32 mb flash; it's not as if the system is swapping to it! At maybe one write a week to some random sector of my flash, I have well, a very long expected lifetime for it. -- see shy jo
msg21760/pgp00000.pgp
Description: PGP signature
