| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
On Fri, May 09, 2003 at 03:21:00PM -0700, Joe DiMartino wrote:
> On Fri, 2003-05-09 at 14:59, Cahill, Ben M wrote:
> > > -----Original Message-----
> > > From: Joe DiMartino [mailto:joe@osdl.org]
> > > Sent: Thursday, May 08, 2003 7:15 PM
> > > To: Open GFS
> > > Subject: [ogfs-dev]some benchark data
> > >
> >
> > >
> > > real time (seconds):
> > > =========
> > > untar u/ext3 tar t/ext3 rm r/ext3
> > > ------ ------ ------ ------ ------ ------
> > > ext3 34.48 1.00 0.25 1.00 1.23 1.00
> > >
> > > nolock 46.77 1.36 1.58 6.32 45.95 37.36
> > >
> > > memexp 49.66 1.44 2.93 11.72 50.24 40.85
> > >
> >
> > I just realized that there is not much difference between the nolock and
> > memexp runs! I'm surprised, because we've been expecting that locking was a
> > big performance roadblock.
>
> That is why I want to get profile working! I was also surprised.
> I thought nolock would be really close to ext3 (ext2 at least).
Don't forget that all the locks are cached in the glock code once
they have been accessed once. The penalty through memexp locking
is not this big on a single node. It becomes worse quickly with
more nodes.
All I expect to learn from a one node benchmark is how efficient
the disk structures and the algorithms in the code are *in the
best case*, i.e. when the file system is clean. I fully expect
that the numbers get worse on a tight file system and/or after
long use periods.
> > Maybe journaling is the pig? If I read the code right, journaling writes
> > file data twice, once for the journal (using "temporary" bh's), and once for
> > the actual write (using "real" bh's). I'm not very sure that my code
> > reading is correct!
>
> I didn't find a mount option (or mkfs option) for doing data journaling,
> so I assumed that ogfs only does metadata journaling. Are you sure it
> writes file data to the journal? Or is the second write really the
> flush of metadata from the journal?
Ogfs journaling writes only meta data.
> > But it's interesting how similar the untar results are
> > to the rm results.
> > Could it be that ogfs writes the data (or 0s?) yet
> > again, to both journal and filesystem, when erasing files? (Pure guesswork
> > here).
No. But a single write transaction requires:
1) Reading the old meta data
2) Synchronously writing the journal record to declare the
transaction (storing the old meta data)
3) Asynchronously writing the file data and the new meta data.
4) After (3) completes, synchronously (?) invalidating the
journal record.
So, there is plently of potential disk activity.
> Does anyone know a good way to measure the amount of I/O at the
> partition granularity during a test?
> I sure liked sar or iostat, but I don't know of a linux tool for
> this.
How about sar or iostat? ;-) Google for "atsar".
Bye
Dominik ^_^ ^_^
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com
_______________________________________________
Opengfs-devel mailing list
Opengfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opengfs-devel