On Sun, 2009-01-18 at 07:17 -0800, Sunil Mushran wrote: > How big is this disk? Maybe one kernel tree untar is not be enough to > expose the original issue. Also, use ls -i and/or debugfs to see if > the inodes have some locality.
Tao, sunil I've tested it out with more attempts, it may have something to do with the disk size. but the root pause why i did not get a excited speed-up performance gain was due to the iscsi-target(iscsi server) cache. the operation in your testcase which was meant for cache dropping is aimed at client side(a 'echo 2>/proc/sys/vm/drop_cache' only flush the fs's cache for iscsi initor(isci client)). Tao, You can verify this by pausing the tests at the right point before we start '2rd ls -lR', then flush the iscsi-target's cache by 'service iscsi-target restart'(there may be a more graceful way to do this),after this done, resume the tests, then you'll find the the realtime it consumed will be up to 3 mins around:) Btw, i really saw lots of locality by 'ls -li' for inodes under a same dir, take /mnt/ocfs2/linux-2.6.28/include/linux for instance, almost all of its inodes are contiguous one by one regarding to its inode number. Regards, Tristan > > On Jan 18, 2009, at 12:58 AM, Tao Ma <[email protected]> wrote: > > > > > > > tristan.ye wrote: > >> On Fri, 2009-01-16 at 16:16 +0800, Tao Ma wrote: > >> > >>> tristan.ye wrote: > >>> > >> Tao, > >> > >> I've done 10 times tests with single-node testcase repeatly, > >> following > >> is a average statistic reports > >> =============== Tests with 10 times iteration================ > >> > >> 1st 'Tar xjvf' result: > >> > >> Average real time with 10 times: > >> Original kernel kernel with enhanced > >> patches > >> 0m 43.578s 0m 49.355s > >> > >> 1st 'ls -lR' result: > >> Average real time with 10 times: > >> Original kernel kernel with enhanced > >> patches > >> 0m 23.622s 0m 23.508s > >> > >> 1st 'rm -rf' result: > >> Average real time with 10 times: > >> Original kernel kernel with enhanced > >> patches > >> 0m 57.039s 0m 58.612s > >> > >> 2rd 'Tar xjvf' result: > >> Average real time with 10 times: > >> Original kernel kernel with enhanced > >> patches > >> 0m 49.550s 0m 52.214s > >> > >> 2rd 'ls -lR' result: > >> Average real time with 10 times: > >> Original kernel kernel with enhanced > >> patches > >> > >> 0m 23.591s 0m 23.487s > >> > >> ===============Tests end============================ > >> > >> > >>> From above tests, we really have had a speed-up performance gain > >>> when > >> traversing files by 'ls -lR' against a kernel tree:),but seems also > >> encountered a performance lose when populating the files by 'tar > >> xvjf' > >> according to the contrast tests. > >> > > I am just a little confused with your test result. Especially the > > last one. > > from the statistics, it looks that there is almost no performance gain > > comparing 0m23.591s with 0m 23.487s. > > But I see >2mins every time. So are you sure of it? > > anyway, thanks for your test and I will discuss it with you later. > > > > Regards, > > Tao > > > > _______________________________________________ > > Ocfs2-devel mailing list > > [email protected] > > http://oss.oracle.com/mailman/listinfo/ocfs2-devel _______________________________________________ Ocfs2-devel mailing list [email protected] http://oss.oracle.com/mailman/listinfo/ocfs2-devel
