lkml.org 
[lkml]   [2009]   [Jun]   [22]   [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
    Pavel Machek wrote:
    > On Mon 2009-06-22 10:31:28, Tim Bird wrote:
    >> Pavel Machek wrote:
    >>> I did not see that in the changelog. If it is not general purpose
    >>> filesystem, it is lot less interesting.
    >> PRAMFS is not a general purpose filesystem. Please read
    >> the introductory post to this thread, or look at
    >> http://pramfs.sourceforge.net/ for more information.
    >
    > Yeah, I seen that. It directly contradicts what you say.

    Could you be more specific? In what way does the
    description on the website contradict what I said?

    >> Since the purpose of PRAMFS is to provide a filesystem
    >> that is persistent across kernel instantions, it is not
    >> designed for high speed. Robustness in the face of
    >> kernel crashes or bugs is the highest priority, so
    >> PRAMFS has significant overhead to make the window
    >> of writability to the filesystem RAM as small as possible.
    >
    > Really? So why don't you use well known, reliable fs like ext3?

    Are you sure you read the web site? It directly addresses this
    question. From the web site: "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."

    >> This is not a file system one would do kernel compiles on.
    >> This is where someone would keep a small amount of sensitive
    >> data, or crash logs that one needed to preserve over kernel
    >> invocations.
    >
    > Really? Web page says:
    >
    > #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
    >
    > So you don't cache it "because its fast", and then it is 13MB/sec?

    I'm not sure what you're quoting. The paragraph you quoted doesn't
    have the words "because its fast" [sic]. Speed is not a primary
    consideration for this filesystem. Due to the overhead of changing
    the page flags, it's possible that using the page cache would
    speed up overall access to this filesystem. (This would depend on
    the cost of changing the access flags, and the pattern of operations
    on the filesystem.) However, using the page cache would add
    a level of indirection which would detract from the intended
    robustness.

    -- Tim

    =============================
    Tim Bird
    Architecture Group Chair, CE Linux Forum
    Senior Staff Engineer, Sony Corporation of America
    =============================



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