Prev: [PATCH] USB: musb: fix build error introduced by isoc change
Next: [PATCH] net/sunrpc: Convert (void)snprintf to snprintf
From: Greg Freemyer on 8 Mar 2010 11:40
On Mon, Mar 8, 2010 at 11:22 AM, jim owens <owens6336(a)gmail.com> wrote:
> David Newall wrote:
>> Christian Borntraeger wrote:
>>> Some bigger things are missing in the e4defrag tool:
>>> ...
>>> - overall layout considerations (e.g. putting files close to its
>>> directory or
>>> � use the atime to move often used files to the beginning of a disk etc.)
>>
>> Shouldn't oft-used files be placed closer to the middle? �If you place
>> them at the beginning of the file, it's only possible for the head-stack
>> to be close to the file from the inner direction. �Place them in the
>> middle and it's possible for the head-stack to be close from the outer
>> direction, too, which sounds like a doubling of probability. �It seems
>> that it's the least frequently used files that should be placed at one
>> end of the disk or the other.
>
> No. �Your logic would be correct if rotating disks had
> similar speed at all locations. �Current disks are much
> faster at the 0 end than at the middle or highest address.
>
> It is not unusual to see 2x difference in transfer speed
> so you always want the important stuff as low as possible.
>
> jim

Jim, I should know this, but is sector 0 on the outside edge, or the inner edge?

I assume outer so that the linear speed of the platter under the head
is faster and thus more data per second is passing under the head.

Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: jim owens on 8 Mar 2010 12:20
Greg Freemyer wrote:
>
> Jim, I should know this, but is sector 0 on the outside edge, or the inner edge?
>
> I assume outer so that the linear speed of the platter under the head
> is faster and thus more data per second is passing under the head.

Correct. AFAIK everyone starts 0 at the outer edge for that reason,
it makes for better benchmarks ;)

When I only worried about a few OEM drives, I used to read the zone
geometry from the drive to see where each speed transition was as the
density decreased. But that is just not worth the effort in linux
filesystems IMO, it is enough to pack low.

jim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: jim owens on 9 Mar 2010 08:30
After thinking about it overnight, I realized I think in terms
of 1 drive is 1 filesystem. That is a fatal trap for defragment.

> When I only worried about a few OEM drives, I used to read the zone
> geometry from the drive to see where each speed transition was as the
> density decreased. But that is just not worth the effort in linux
> filesystems IMO, it is enough to pack low.

So I retract that we don't care about zone geometry, we need to
care deeply, but not in the sense of how moving short distances
on a drive affects the performance. What we need to ensure is
that the placer algorithm does not span across partitions as in:

["/" 100GB created] [300GB other] [100G LVM added to "/"]

so the filesystem thinks it is 200GB contiguous and the
defragmenter thinks address 90GB is closer to address 110 GB
than 90GB is to 50GB.

jim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [PATCH] USB: musb: fix build error introduced by isoc change
Next: [PATCH] net/sunrpc: Convert (void)snprintf to snprintf