2009/6/24 Pavel Machek <pavel@xxxxxx>: > On Wed 2009-06-24 19:38:37, Marco wrote: >> >>> Pavel Machek wrote: >> >>>> On Mon 2009-06-22 14:50:01, Tim Bird wrote: >> >>>>> Pavel Machek wrote: >> >>>>>>> block of fast non-volatile RAM that need to access data on it using a >> >>>>>>> standard filesytem interface." >> >>>>>> Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are >> >>>>>> better with ext2. >> >>>>> Not if you want the RAM-based filesystem to persist over a kernel >> >>>>> invocation. >> >>>> Yes, you'll need to code Persistent, RAM-based _block_device_. >> >>> First of all I have to say that I'd like to update the site and make it >> >>> clearer but at the moment it's not possible because I'm not the admin >> >>> and I've already asked to the sourceforge support to have this possibility. >> >>> >> >>> About the comments: sincerely I don't understand the comments. We have >> >>> *already* a fs that takes care to remap a piace of ram (ram, sram, >> >>> nvram, etc.), takes care of caching problems, takes care of write >> >> Well, it looks pramfs design is confused. 13MB/sec shows that caching >> >> _is_ useful for pramfs. So...? >> > >> > caching problems means to avoid filesystem corruption, so dirty pages in >> > the page cache are not allowed to be written back to the backing-store >> > RAM. It's clear that there is a performance penalty. This penalty should >> > be reduced by the access speed of the RAM, however the performance are >> > not important for this special fs as Tim Bird said, so this question is >> > not relevant for me. If this issue is not clear enough on the web site, >> > I hope I can update the information in the future. >> > >> >>> You are talked about journaling. This schema works well for a disk, but >> >>> what about a piece of ram? What about a crazy kernel that write in that >> >>> area for a bug? Do you remember for example the e1000e bug? It's not >> >> I believe you need both journaling *and* write protection. How do you >> >> handle power fault while writing data? >> >> Pavel >> > >> > Ah now the write protection is a "needed feature", in your previous >> > comment you talked about why not use ext2/3....... >> > >> > Marco >> > >> >> Just for your information I tried the same test with pc in a virtual machine with 32MB of RAM: >> >> Version 1.03e ------Sequential Output------ --Sequential Input- --Random- >> -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- >> Machine Size:chnk K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP >> hostname 15M:1k 14156 99 128779 100 92240 100 11669 100 166242 99 80058 82 >> ------Sequential Create------ --------Random Create-------- >> -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- >> files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP >> 4 2842 99 133506 104 45088 101 2787 99 79581 101 58212 102 >> >> These data are the proof of the importance of the environment, workload and so on when we talk >> about benchmark. Your consideration are really superficial. > > Unfortunately, your numbers are meaningless. I don't think so. > Pavel > > (PCs should have cca 3GB/sec RAM transfer rates; and you demosstrated > cca 166MB/sec read rate; disk is 80MB/sec, so that's too slow. If you > want to prove your filesystem the filesystem is reasonably fast, > compare it with ext2 on ramdisk.) > This is the point. I don't want compare it with ext2 from performance point of view. This comparison makes no sense for me. I've done this test to prove that if you change environment you can change in a purposeful way the results. Marco -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
