Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages
Loading