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-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
