2009/6/21 Pavel Machek <pavel@xxxxxx>: > >> >> 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. >> > >> > So... what is the performance difference between ext2 and your new >> > filesystem? >> > >> >> About the "space" you can read a detailed documentation on the site: >> >> http://pramfs.sourceforge.net/pramfs-spec.html > > I do not see any numbers there. Do you think you can save significant > memory when storing for example kernel source trees? There aren't benchmark, but I pointed it out because if you know ext2 you can do a comparison. > >> In addition I can do an example of "compact" information: ext2 uses >> directory entry objects ("dentries") to associate file names to >> inodes, > > I'm not sure that on-disk directory entry == dentry. > >> and these dentries are located in data blocks owned by the parent >> directory. In pramfs, directory inode's do not need to own any data >> blocks, because all dentry information is contained within the inode's >> themselves. > > 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. > >> >From performance point of view: >> >> Sometimes ago I uploaded here (http://elinux.org/Pram_Fs) some benchmark >> results to compare the performance with and without XIP in a real >> embedded environment with bonnie++. You could use it as reference point. > > Well, so XIP helps. ext2 can do XIP too, IIRC. Is your performance > better than ext2? > > Wait... those numbers you pointed me... claim to be as slow as > 13MB/sec. That's very very bad. My harddrive is faster than that. > Pavel > As I said I did the test in a real embedded environment so to have comparable result you should use the same environmente with the same tools, with the same workload and so on. Marco -- 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
