Re: new special filesystem for consideration in 2.6/2.7

From: Steve Longerbeam
Date: Mon Mar 08 2004 - 13:41:48 EST

Stephen M. Kenton wrote:

If the recent news about giga-bit mram being a real possibility in
the not too far future pans out, this may be get more important.

This is a reality in embedded devices. Go read the message again...

Umm, yes and no. I did not mean to dis this proposal because I think it
is worthwhile. Rather, I was thinking about the problems with really
large amounts of data. I don't really think that a few Kilo or Mega
bytes of data needs the same sort of infrastructure that will be
for Tera or Peta bytes. As an extreme example the few bytes of nv ram
in the
cmos clock chips in the original PC/AT did not require much support
the multiple terabytes of data in my raid farm at work would be very
vulnerable under this proposal since a rogue process could cause lots of
damage in very sort order as would losing a memory bank to hardware

In the last discussion I saw on the topic on lkml, there was discussion
whether to even preserve the volume/directory/file abstraction at all
memory mapped data spaces. That discussion was quite speculative given
the lack of affordable *really large* nvram type storage to compete with
100+ gigabyte disks and even larger raids. That situation may be
Hence, this may become more important.

Hi Steve, I should note that pramfs was not designed with *really large* nvram
storage in mind. It was more designed to use space efficiently on small amounts
of nvram. For instance, pramfs inodes only have a 2-d block pointer table
(vs ext2/ext3's 3-d i_block[14] pointer table), so the max file size is (b/4)^2
blocks or b^3/16 bytes, b being the blocksize. Also, offsets within the fs are unsigned
long's, so there's a 4 gig limit already on 32-bit machines.

So in short, for 10s or even 100s of MB, pramfs is fine, but for GB or more
storage it's not an appropriate fs.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at