| 1 |
Apparently, though unproven, at 00:13 on Saturday 20 November 2010, Mick did |
| 2 |
opine thusly: |
| 3 |
|
| 4 |
> On Friday 19 November 2010 19:19:34 David W Noon wrote: |
| 5 |
> > On Fri, 19 Nov 2010 17:00:04 +0100, Peter Humphrey wrote about Re: |
| 6 |
> > |
| 7 |
> > [gentoo-user] migrating disks (from mounts to disklabels: |
| 8 |
> > >On Friday 19 November 2010 14:42:23 Neil Bothwick wrote: |
| 9 |
> > >> On Fri, 19 Nov 2010 10:52:50 +0000, Mick wrote: |
| 10 |
> > >> > Also primary partitions which he does not seem to be using at all |
| 11 |
> > >> > have a slight edge over logical. |
| 12 |
> > >> |
| 13 |
> > >> Do you have any data on this? I generally use all logical partitions |
| 14 |
> > >> but could be persuaded to rethink. |
| 15 |
> > > |
| 16 |
> > >Well there must be one level of indirection on first access, since the |
| 17 |
> > >start of the logical partition has to be looked up in a "primary" |
| 18 |
> > >partition, but I can't imagine that being needed more than once per |
| 19 |
> > >reboot. |
| 20 |
> > |
| 21 |
> > Correct. |
| 22 |
> > |
| 23 |
> > The same applies to LVM2 or EVMS logical volumes: a small "lookup" |
| 24 |
> > penalty (a few milliseconds) when the filesystem is first |
| 25 |
> > activated/mounted, and as fast as the drive itself thereafter. |
| 26 |
> |
| 27 |
> Short of measuring the latency with some system (which I wouldn't know how) |
| 28 |
> I have experimented with setting the /boot partition on primary and |
| 29 |
> logical partitions and the difference (on a stopwatch) was measurable in |
| 30 |
> seconds betweeen having said partition on a primary and having it on a |
| 31 |
> logical. Furthermore, sda7 was slower than sda5. |
| 32 |
> |
| 33 |
> I haven't measured latencies for first mount and subsequent look ups. I |
| 34 |
> thought that it would be the same every time a partition fs is being |
| 35 |
> accessed, no? |
| 36 |
|
| 37 |
|
| 38 |
Not at all. There's this thing the kernel does called caching. |
| 39 |
|
| 40 |
Yes, I know you can invalidate the entire cache and force the next read to |
| 41 |
come from disk, but that is completely devoid of reality. Very very few |
| 42 |
machines actually do that or anything remotely similar. So measuring it does |
| 43 |
give pretty numbers, pretty meaningless numbers. |
| 44 |
|
| 45 |
The kernel will cache the entire partition layout scheme and any mapping it |
| 46 |
needs in order to determine where blocks lie on the disk. Any thought that it |
| 47 |
won't is just so bat-shit insane and so far out there it's not even worth |
| 48 |
contemplating. |
| 49 |
|
| 50 |
Thus, the question that sparked this thread off is entirely moot. |
| 51 |
|
| 52 |
-- |
| 53 |
alan dot mckinnon at gmail dot com |
Archives