[sclug] performance puzzle

[Alex Butcher]

On Sun, 10 Jul 2005, Tom Dawes-Gamble wrote:

> 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

OK, so the LV consists of a single segment, rather than many after being
resized a few times already, possibly resulting in a heavily fragmented LV.
As an aside, I've noticed problems with 'mkisofs | cdrecord' pausing and
subsequently failing when burning directly from files read from a LV created
and extended several times under RH8.

[snip]

> 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.

[snip timings]

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

OK, that's more interesting.

> 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.

*You* don't. The drive firmware does, without you knowing or having any
control over it.

One thing I'm not clear about; is this an actual problem you're
experiencing, or /just/ a puzzle?

Also, can you run 'du -sch' on all the files in the test, please?

I have my suspicions as to what you're doing (or, more specifically, what
the creation tool is doing) but unfortunately, my discs are not slow enough
to replicate the speed differential. :-P

> regards,
> Tom.

Best Regards,
Alex.
-- 
Alex Butcher      Brainbench MVP for Internet Security: www.brainbench.com
Bristol, UK                      Need reliable and secure network systems?
PGP/GnuPG ID:0x271fd950                         <http://www.assursys.com/>