Messages in this thread | | | Date | Mon, 22 Jun 2009 20:07:06 +0200 | From | Marco <> | Subject | 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
| |