FlashDisk vs RamDisk+FlashDisk partitions

Andrei Bulucea [email protected]
Fri, 5 Jan 2001 16:18:01 -0800 (PST)


Thank you for the info. I like the mixed aproach because it tends to
save RAM. In my case, my flash build is quite large 64Mb (not because
of peewee), therefore I need to allocate another 64RAM for ramdisk
plus some for the OS...

The trick is mount/unmounting the /etc flash partition in order   
to save changes, if any. I suspect that changes on /etc
are not as dynamic (system settings), hence mounting/unmounting 
can be done on demand. 

> Future kernel releases will include devfs and reiserfs or ext3. devfs
> allows for a virtual device filesystem, similar to how /proc works.

Excellent! Will this be on 2.4 or 2.2.x? Just curious... (very)

Thank you so much!

------------------------------------------------------------------
Andrei Bulucea				Ituner Network Operations
Ituner Networks Corp.			Email: [email protected]
3071 Southwycke Terrace			Voice: 800-97-TUNER
Fremont, CA 94536			Fax:   510-795-8855 
U.S.A. 					http://www.ituner.com
------------------------------------------------------------------


On Fri, 5 Jan 2001, Adi Linden wrote:

> Hi Andrei,
> 
> PeeWeeLinux supports different ways of loading a target device. This
> includes having a single large partition on the flash drive (ext2 or FAT)
> that contains the kernel and ramdisk image (compressed filesystem). In
> this arrangement there is no easy way to save anything, though.
> 
> Another alternative (already in PeeWeeLinux) is to have an uncompressed
> filesystem on flash which is loaded into memory and run from a ramdisk.
> This allows for the flash to be mounted (read-write) and changes to be
> made that will take effect once the system is rebooted.
> 
> Lastly there is a mixed approach. Quite close to your #1 suggestion. Have
> a read-only root partition on flash. Load /etc, /dev/ and /var into 
> ramdisks. The reason for /etc is that the system needs write access to
> some files in /etc, the reason for /dev is that in order to write to
> devices the partition the node is created on needs to be writable. And
> /var you've explained already. Depending on how the /etc branch is created
> it could be saved to flash by mounting the appropriate partition
> read/write.
> 
> Future kernel releases will include devfs and reiserfs or ext3. devfs
> allows for a virtual device filesystem, similar to how /proc works. This
> would eliminate the need for a /dev ramdisk and preserve a moderate amount
> of memory and flash since each device currently consumes one inode on the
> filesystem it resides on.
> 
> You can corrupt flash if you remove power during a write operation.
> Apparently ext3 and reiserfs would automatically recover and fall back to
> a last known good state. Now that's my understanding based on rumours
> rather than research on my part.
> 
> The read-only root filesystem with ramdisks for /etc, /var and /dev
> that's implementedin PeeWeeLinux works but it could use some more fine
> tuning, I think.
> 
> TTYL,
> Adi
> 
>   
> 
> On Fri, 5 Jan 2001, Andrei Bulucea wrote:
> 
> > Happy New Year everybody! 
> > 
> > While reading your postings I noticed  some
> > messges related to fsck/journaling filesystem
> > implementations for PeeWeeLinux. 
> > 
> > How about having the folowing ramdisk/flashdisk arrangement
> > thus avoiding running fsck based on the assumption that
> > fsck gets invoked due to a *modified* filesystem, not corruption,
> > (CF doesn't get corrupted on power off)
> > 
> > 1) I think it is quite possible to have your / partition
> > ,read only, mounted on the FlashDisk and something like
> > /var mounted on a ramdisk. So your endless logging and 
> > 'scratchpad area' will be volatile, therefore each time the 
> > machine crashes or is powered off, /var will be lost, but no 
> > changes will be recorded on "/" filesystem, therefore fsck 
> > will not be invoked.
> > 
> > 2) Compress the entire filesystem into the FlashDisk and
> > then load it into RamDisk. This consumes more RAM, but it 
> > seems to be the fastest, however costly due to the fact 
> > that the compression radio is 1:3 and CF/RAM price ratio 
> > is only 1:2...  
> > 
> > Am I missing something? I prefer #1, Which one would you choose?
> > 
> > Best Regards and thank you in advance,
> > Andrei
> > 
> > ---------------------------------------------------
> > See the list archives at http://adis.on.ca/archives/
> > See the PWL homepage at  http://peeweelinux.com
> > ---------------------------------------------------
> > 
> 
> ---------------------------------------------------
> See the list archives at http://adis.on.ca/archives/
> See the PWL homepage at  http://peeweelinux.com
> ---------------------------------------------------
> 

---------------------------------------------------
See the list archives at http://adis.on.ca/archives/
See the PWL homepage at  http://peeweelinux.com
---------------------------------------------------