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:
>>>>> How do you handle hard-links, then?
>>>> Indeed hard-links are not supported :) Due to the design of this fs
>>>> there are some limitations explained in the documentation as not
>>>> hard-link, only private memory mapping and so on. However this
>>>> limitations don't limit the fs itself because you must consider the
>>>> special goal of this fs.
>>> 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.
>

I don't think, I think it's very clear:

"In summary, PRAMFS is a light-weight, full-featured, and
space-efficient special filesystem that is ideal for systems with a
block of fast non-volatile RAM that need to access data on it using a
standard filesytem interface."


>> 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?
>
>> 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?
>
> Pavel


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