Re: new special filesystem for consideration in 2.6/2.7

[Steve Longerbeam <stevel@mvista.com>]

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
>required
>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
>while
>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
>failure.
>
>In the last discussion I saw on the topic on lkml, there was discussion
>about
>whether to even preserve the volume/directory/file abstraction at all
>for
>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
>changing.
>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.

Steve