[Ocfs2-devel] [PATCH 0/3] ocfs2: Inode Allocation Strategy Improvement.v2

[tristan.ye]

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 <tao.ma at oracle.com> 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
> > Ocfs2-devel at oss.oracle.com
> > http://oss.oracle.com/mailman/listinfo/ocfs2-devel