[lug] RAM based files, file systems

[Bear Giles]

Jordan Crouse wrote:
> Yes.  The loopback device is really a cheap substitute for real physical media.  Its a great way to check out small filesystems that for one reason or another aren't pratical to put on the media (such as an CD image you just burned, or something for an embedded device).  I've mounted some pretty big images as loopback before, so I would assume that some sort of read caching must go on in the background.  Any write changes would probably be cached until you unmount or sync.  More on that later....

The loopback device can be much more.  There's an encryption mode 
which is an excellent way to provide encrypted partitions since it 
will support *any* filesystem.  There's also perennial talk of 
adding a compression mode, but it's tricky for various reasons.

>>I know knoppix does something related to this.  There's an iso image
>>that is cramfs'ified and then mounted via the loopback.

Cramfs and cromfs are specialized read-only filesystem.  The 
initial ramdisk (initrd when you're building kernels) is a cramfs, 
iirc.

They're not really suitable for large partitions.  I've created 
bootable ISO images that use a 16MB ramdisk and three tmpfs for /, 
/usr, /var and /lib (I think) - the initrd runs a script that 
unpacks four compressed tarballs on the CD and mounts the 
memory-based partitions in the right places.  It's a weird little 
beast - it's a basic Debian system that fits into about 100MB of 
ram, and comes up with the CD mounted as an apt-able repository 
with hundreds of additional packages available for installation.

> Recall that you have the option to mount a filesystem either 
 > read-only or read-write.

Cramfs and cromfs (and iso9660?) can only be mounted read-only - 
the drivers don't support updates.

>>So how does the in RAM fs work (it's obvious that knoppix is exceeding
>>the 4k limit

You can set the ramdisk size as a kernel option, either when you 
compile it or on the boot command line.