lkml.org 
[lkml]   [2009]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem

Jamie Lokier wrote:
> Marco wrote:
>> Linux traditionally had no support for a persistent, non-volatile
>> RAM-based filesystem, persistent meaning the filesystem survives a
>> system reboot or power cycle intact. The RAM-based filesystems such as
>> tmpfs and ramfs have no actual backing store but exist entirely in the
>> page and buffer caches, hence the filesystem disappears after a system
>> reboot or power cycle.
>
> Why is a ramdisk not sufficient for this?
>

Simply because the ramdisk was not designed to work in a persistent
environment. In addition this kind of filesystem has been designed to
work not only with classic ram. You can think at the situation where you
have got an external SRAM with a battery for example. With it you can
"remap" in an easy way the SRAM. Moreover there's the issue of memory
protection that this filesystem takes care.

> Why is an entire filesystem needed, instead of simply a block driver
> if the ramdisk driver cannot be used?
>

>From documentation:

"A relatively straight-forward solution is to write a simple block
driver for the non-volatile RAM, and mount over it any disk-based
filesystem such as ext2/ext3, reiserfs, etc.

But the disk-based fs over non-volatile RAM block driver approach has
some drawbacks:

1. Disk-based filesystems such as ext2/ext3 were designed for optimum
performance on spinning disk media, so they implement features such
as block groups, which attempts to group inode data into a contiguous
set of data blocks to minimize disk seeking when accessing files. For
RAM there is no such concern; a file's data blocks can be scattered
throughout the media with no access speed penalty at all. So block
groups in a filesystem mounted over RAM just adds unnecessary
complexity. A better approach is to use a filesystem specifically
tailored to RAM media which does away with these disk-based features.
This increases the efficient use of space on the media, i.e. more
space is dedicated to actual file data storage and less to meta-data
needed to maintain that file data.

2. If the backing-store RAM is comparable in access speed to system memory,
there's really no point in caching the file I/O data in the page
cache. Better to move file data directly between the user buffers
and the backing store RAM, i.e. use direct I/O. This prevents the
unnecessary populating of the page cache with dirty pages. However
direct I/O has to be enabled at every file open. To enable direct
I/O at all times for all regular files requires either that
applications be modified to include the O_DIRECT flag on all file
opens, or that a new filesystem be used that always performs direct
I/O by default."

On this point I'd like to hear other embedded guys.

> It just struck me as a lot of code which might be completely
> unnecessary for the desired functionality.
>
> -- Jamie
>






\
 
 \ /
  Last update: 2009-06-14 09:23    [W:0.711 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site