lkml.org 
[lkml]   [2009]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
    From
    2009/6/17 Chris Friesen <cfriesen@nortel.com>:
    > Marco wrote:
    >> This is a second attempt at mainlining Pramfs. The first attempt was
    >> back in early 2004 by MontaVista. Since then the kernel code has almost
    >> been completely rewritten. So my first item on the list was porting the
    >> code on a recent kernel version. After that I added the XIP support.
    >>
    >> Now some FAQs:
    >>
    >> What is the goal of this filesystem?
    >>
    >> Many embedded systems have a block of non-volatile RAM separate from
    >> normal system memory, i.e. of which the kernel maintains no memory page
    >> descriptors. For such systems it would be beneficial to mount a
    >> fast read/write filesystem over this "I/O memory", for storing
    >> frequently accessed data that must survive system reboots and power
    >> cycles. An example usage might be system logs under /var/log, or a user
    >> address book in a cell phone or PDA.
    >
    > Nice to see something like this submitted to mainline.  We use something
    > similar to provide persistent storage for crash recovery debug data for
    > boards which don't have local storage.
    >
    > In many cases kdump can provide good information, but it's not
    > sufficient for "flight recorder" type data if the kernel gets rebooted
    > by a hardware mechanism (watchdog, for instance) that doesn't give a
    > pre-interrupt.

    I'm very happy that this fs has the approval of the kernel community. :)

    >
    > I'm a bit concerned about your PTE modifications on every write
    > though...we do things like log every exception and scheduler operation
    > to persistent memory, and I think the overhead of changing the
    > protection on every write would be a killer.  Instead, we make extensive
    > use of checksums at various different levels so that the recovery app
    > can determine which data is valid.
    >

    It's a trade-off between security and performance. Checksum it's a
    good way to understand if a data is valid or not (indeed it's used in
    this fs), but with this schema you can prevent the system to do
    something wrong. This option, however, can be enabled/disabled via
    kconfig.

    > Also, I'd like to ensure that direct memory access to the memory area
    > would be available.

    What do you exactly mean with this? Can you explain to me a bit deeper?

    > There are some things (like the sched/exception logging mentioned above) where we want to make accesses as fast as possible.
    >
    > Chris
    >
    >

    Marco
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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