Single disk parrallelization

Single disk parrallelization

[Jeb Thomson]

With the advanced features of btrfs, it would be an additional simple task to make different platters run in parallel. 

In this case, say a disk has three platters, and so three seek heads as well. If we can identify that much, and what offsets they are at, it then becomes a trivial matter to place the reads and writes to different platters at the same time. 

In affect, this means each platter should be operating as a single virtualized unit, instead of one single unit...

Regards,

Re: Single disk parrallelization

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

On 2014-09-19 14:10, Jeb Thomson wrote:
> With the advanced features of btrfs, it would be an additional simple task to make different platters run in parallel.
>
> In this case, say a disk has three platters, and so three seek heads as well. If we can identify that much, and what offsets they are at, it then becomes a trivial matter to place the reads and writes to different platters at the same time.
>
> In affect, this means each platter should be operating as a single virtualized unit, instead of one single unit...
>
In theory this is a great idea except for two things:
1) Most consumer drives have only one platter.
2) The kernel doesn't have such low-level hardware access, so it would 
have to be implemented in device firmware (and I'd be willing to bet 
that most drive manufacturers already stripe data across multiple 
platters when possible).



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: Single disk parrallelization

[Ralf-Peter Rohbeck]

On 09/19/2014 11:10 AM, Jeb Thomson wrote:
> With the advanced features of btrfs, it would be an additional simple task to make different platters run in parallel.
>
> In this case, say a disk has three platters, and so three seek heads as well. If we can identify that much, and what offsets they are at, it then becomes a trivial matter to place the reads and writes to different platters at the same time.
>
> In affect, this means each platter should be operating as a single virtualized unit, instead of one single unit...
>
> Regards,
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
A disk drive has only one actuator that moves all heads in parallel. 
Also disk drives are an array of logical blocks today; nobody uses 
cylinder/head/sector addressing any more.

Re: Single disk parrallelization

[Calvin Walton]

On Fri, 2014-09-19 at 13:10 -0500, Jeb Thomson wrote:
> With the advanced features of btrfs, it would be an additional 
> simple task to make different platters run in parallel.
> 
> In this case, say a disk has three platters, and so three seek heads 
> as well. If we can identify that much, and what offsets they are at, 
> it then becomes a trivial matter to place the reads and writes to 
> different platters at the same time.
> 
> In affect, this means each platter should be operating as a single 
> virtualized unit, instead of one single unit... 
> 

If you look at a disk benchmark of a modern multi-platter drive, e.g.
http://www.anandtech.com/show/8265/wd-red-pro-review-4-tb-drives-for-nas-systems-benchmarked/4
(All of the drives in this review have 4 or 5 platters)
You'll see that the performance is a fairly smooth curve down from max 
speed (outer edge of the platters) to min speed (inner edge of the 
platters).

Since this is a smooth curve, rather than starting high, going down, 
then starting high on the next platter and going down again, this 
means that the drive controller is already writing to all of the 
platters at the same time - or at the very least, writing in a striped 
pattern between platters without moving the seek heads. There's 
nothing you could do at the OS level which would make it faster 
(besides preferring to read and write at the lower LBAs of the drive).

-- 
Calvin Walton <calvin.walton@kepstin.ca>