filesystem for initrd

filesystem for initrd

[Art Boulatov]

Hi,

I'm in the process of creating a custom "system partition"
for out Linux servers, which is actually an initial ramdisk,
coming from hd or network on boot
to load necessary drivers and perform important checks
before the real filesystems get mounted,
and I did not find any info on
what filesystems can I use
for initrd, are there any restrictions?
Mostly interested in cramfs,
due to it's compression.

Could anybody help me work this out or point to the right place for more 
info?

Thanks a lot,
Art.

Re: filesystem for initrd

[Jeff Garzik]

Art Boulatov wrote:
> I'm in the process of creating a custom "system partition"
> for out Linux servers, which is actually an initial ramdisk,
> coming from hd or network on boot
> to load necessary drivers and perform important checks
> before the real filesystems get mounted,
> and I did not find any info on
> what filesystems can I use
> for initrd, are there any restrictions?
> Mostly interested in cramfs,
> due to it's compression.

Any filesystem which works with a normal block device, such as a hard
drive, will work with a ramdisk.  Read ramdisk.txt and initrd.txt in the
linux/Documentation directory, in your Linux kernel source tree.

cramfs is nice but still read-only at the moment...  You might be able
to get away with stacking ramfs on top of that.  If not, it shouldn't be
hard to modify cramfs so that it allows fs modifications... just stick
the updated pages in RAM until the file is unlinked or the fs is
unmounted.

-- 
Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie

Re: filesystem for initrd

[Ingo Oeser]

On Sat, Mar 10, 2001 at 07:28:53PM -0500, Jeff Garzik wrote:
> cramfs is nice but still read-only at the moment...  You might be able
> to get away with stacking ramfs on top of that. 

What is easier because this ...

> If not, it shouldn't be hard to modify cramfs so that it allows
> fs modifications...  just stick the updated pages in RAM until
> the file is unlinked or the fs is unmounted.

... will lead into problems accounting available space on the fs,
since openers don't expect that they cannot write to a file
anymore, just because we we are out of RAM for backing the
writes.

I think unionfs will care for this kind of problems once we have
it implemented in an official tree.

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
         <<<<<<<<<<<<       come and join the fun       >>>>>>>>>>>>