All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Thornber <thornber@btconnect.com>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] HUGE LVM log file...
Date: Wed, 18 Jul 2001 10:33:21 +0100	[thread overview]
Message-ID: <20010718103321.A540@btconnect.com> (raw)
In-Reply-To: <5.0.2.1.2.20010718104547.00a40ec0@193.0.0.208>; from bs@infologic.fr on Wed, Jul 18, 2001 at 10:48:55AM +0200

On Wed, Jul 18, 2001 at 10:48:55AM +0200, Benoit SERRA wrote:
> At 18/07/01, you wrote:
> >We've not had much feedback on this, I guess that people don't really
> >notice much of a difference, I certainly haven't.  The allocation
> >policy for PE's is to start at the beginning of the disk (which tend
> >to have faster data transfer rates) and work back.  Anybody done any
> >benchmarking in this area ?
> >
> 
> Are you sure ?

No.

I'm just talking transfer rate here, and am just going on the typical
benchmark graphs you see in reviews. eg,

http://www6.tomshardware.com/storage/01q2/010614/barracuda-05.html#data_transfer_diagram

This comment is interesting:

"Seagate uses horizontal mapping with this drive, so that it reaches
maximum performance at the beginning of the medium, decreasing at the
end of the medium."

So obviously this varies from drive to drive.

> In AIX, the system create PPS (PE) from the middle of the disk for 
> performance reasons.

If people really think this would be of benefit we can always provide
another allocator.  Does it allocate to alternate sides of the middle ?

eg, middle, middle + 1, middle - 1, middle + 2 etc ... ?

If so you have to take the extra seek times into account if you're streaming
files that are bigger than the PE size.

This can also fragment your PV; if you create the first LV to take up
half the PV, and it puts this in the middle, a subsequent LV of the
same size ends up having a monster seek in the middle of it - though
it depends on your filesystem if this is an issue.
 
> I heard on this list or on Linux-raid list that it's the middle of the disk 
> which is the faster area.

Depends what you mean by 'faster', data transfer rate or seek time ?

- Joe

  reply	other threads:[~2001-07-18  9:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-17 21:52 [linux-lvm] HUGE LVM log file Gonyou, Austin
2001-07-18  0:00 ` Wolfgang Weisselberg
2001-07-18  8:22 ` Joe Thornber
2001-07-18  8:48   ` Benoit SERRA
2001-07-18  9:33     ` Joe Thornber [this message]
2001-07-18 19:23       ` Ragnar Kjørstad
2001-07-18 22:22         ` lembark
2001-07-18  9:46     ` Adam Cioccarelli
     [not found]     ` <Pine.LNX.4.33.0107181141480.25686-100000@vie-ac.office.ece tra.com>
2001-07-18  9:47       ` Benoit SERRA
2001-07-18 10:48         ` [linux-lvm] what happens when hdX get hdY in a VG Oliver Jovic
2001-07-18 10:59           ` Joe Thornber
2001-07-18 13:29         ` [linux-lvm] HUGE LVM log file Iain Campbell
2001-07-18 17:02     ` Steven Lembark
  -- strict thread matches above, loose matches on Subject: below --
2001-07-17 11:13 Guennadi Liakhovetski
2001-07-17 11:14 ` Heinz J. Mauelshagen
2001-07-17 11:28   ` Guennadi Liakhovetski
2001-07-17 11:28     ` Heinz J. Mauelshagen
2001-07-17 21:28     ` Wolfgang Weisselberg
2001-07-18 14:55       ` Heinz J. Mauelshagen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010718103321.A540@btconnect.com \
    --to=thornber@btconnect.com \
    --cc=linux-lvm@sistina.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.