[sclug] performance puzzle

[Tom Dawes-Gamble]

On Sat, 2005-07-09 at 23:38 +0100, Alex Butcher wrote:
> On Sat, 9 Jul 2005, Tom Dawes-Gamble wrote:
> 
> > On Sat, 2005-07-09 at 13:27 +0100, Alex Butcher wrote:
> >> On Sat, 9 Jul 2005, Tom Dawes-Gamble wrote:
> >>> On Wed, 2005-01-19 at 22:57 +0000, Tom Dawes-Gamble wrote:
> >>>> Why does foo perform so much better than bar or baz?
> >>
> >> In this case, I'd suggest that foo is stored in a faster or more-dense zone
> >> of the disc. Is /mnt/tmp on a logical volume?
> >
> > Yes it is.
> 
> What does 'lvdisplay' say about the LV?

# lvdisplay -v /dev/VolGroup00/lvol0
    Using logical volume(s) on command line
  --- Logical volume ---
  LV Name                /dev/VolGroup00/lvol0
  VG Name                VolGroup00
  LV UUID                ufzk9I-mPae-8kTr-TL0r-Nv7B-NIlM-XGtBjB
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                15.62 GB
  Current LE             500
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:2


> 
> Note also, that conceivably, all bets are off as to which part of the disc
> is used for which files once you use LVM. Modern discs have a significantly
> higher data rate at the rim than the hub, due to there being a greater
> number of physical blocks per track in the hubward cylinders and the disc
> spinning at a constant angular velocity:
> 

Well I have no idea were on the disk the files are  placed.  But just to
prove the point I created a new copy of foo.  Here is what I did.

rm -f bar2 bar3
mv foo fast
ran the tool to make a new foo.

Since I renamed foo it is still in the fast part of the disk.
Since I removed bar2 and bar3 any new file could go in the possibly now
fragmented part of the disk.  

# ll /mnt/tmp
total 2099272
-rw-r--r--  1 root root 1073742848 Jan 19 16:33 bar
-rw-r--r--  1 root root 1073742848 Jan 19 16:34 baz
-rw-r--r--  1 root root 1073742848 Jan 19 16:31 fast
-rw-r--r--  1 root root 1073742848 Jul  9 23:50 foo

# for i in foo fast baz bar foo
> do
> time md5sum $i
> done
4763dafae2d293e98b62979a00308158  foo

real    0m4.489s
user    0m3.062s
sys     0m1.411s
4763dafae2d293e98b62979a00308158  fast

real    0m4.603s
user    0m3.157s
sys     0m1.378s
4763dafae2d293e98b62979a00308158  baz

real    0m21.488s
user    0m2.922s
sys     0m1.251s
4763dafae2d293e98b62979a00308158  bar

real    0m21.144s
user    0m2.983s
sys     0m1.215s
4763dafae2d293e98b62979a00308158  foo

real    0m4.638s
user    0m3.140s
sys     0m1.401s
#

Note that the old foo (fast) and the new foo have similar times but bar
and baz still perform badly.

Believe me it has nothing to do with where the file is on disk.


> I'm pretty sure this was the conclusion we came to the last time you raised
> this issue and that you were surprised modern discs used zoned recording
> techniques.
> 

Yes but I'm not using those techniques to create the file.  I'm just
letting the system do it's own thing.  It's Fedora Core 3.  Installed
using LVM.  I made no changes to the install.

The file system was created using 

mkfs -t ext3 /dev/VolGroup00/lvol0

The mount was a simple

mount  /dev/mapper/VolGroup00-lvol0 /mnt/tmp

> Something else I neglected to mention was ext3's mount options, including
> the 'data=' option to set what is journalled, and the cache policy. It's
> also possible to set the interval at which the journal is committed to disc
> using the 'commit=' option. The VM 'Laptop mode' can achieve a similar
> effect, but globally.
> 
regards,
Tom. 
-- 
There are 10 types of people in the world.
Those that understand Binary and those that don't.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.tmdg.co.uk/pipermail/sclug/attachments/20050710/2723b209/attachment.bin