Benefits from computing physical IDE disk geometry?

Benefits from computing physical IDE disk geometry?

Post by Timothy Mille » Mon, 14 Apr 2003 00:50:05



I'm e*d about the new I/O scheduler (proposed?) in the 2.5.x kernel, but
I have to admit to a considerable amount of ignorance of its actual
behavior.  Thus, if it already does what I'm talking about, please feel free
to ignore this post.  :)

Any good SCSI drive knows the physical geometry of the disk and can
therefore optimally schedule reads and writes.  Although necessary features,
like read queueing, are also available in the current SATA spec, I'm not
sure most drives will implement it, at least not very well.

So, what if one were to write a program which would perform a bunch of
seek-time tests to estimate an IDE disk's physical geometry?  It could then
make that information available to the kernel to use to reorder accesses
more optimally.  Additionally, discrepancies from expected seek times could
be logged in the kernel and used to further improve efficiency over time.
If it were good enough, many of the advantages of using SCSI disks would
become less significant.

Ideas?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by John Bradfor » Mon, 14 Apr 2003 12:00:20


Quote:> Any good SCSI drive knows the physical geometry of the disk and can
> therefore optimally schedule reads and writes.  Although necessary features,
> like read queueing, are also available in the current SATA spec, I'm not
> sure most drives will implement it, at least not very well.

> So, what if one were to write a program which would perform a bunch of
> seek-time tests to estimate an IDE disk's physical geometry?  It could then
> make that information available to the kernel to use to reorder accesses
> more optimally.  Additionally, discrepancies from expected seek times could
> be logged in the kernel and used to further improve efficiency over time.

On a system that's been set up with one large root partition, and
nothing else, you might get a noticable gain, but I would guess that
you could get a simliar gain by partitioning the disk and manually
placing, E.G. /var near the outside of the disk, and things like /etc
near the centre.  I.E. placing more active partitions on faster areas
of the disk.

Quote:> If it were good enough, many of the advantages of using SCSI disks would
> become less significant.

Not really - there are still a lot of advantages of SCSI that it
wouldn't address.

John.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by Nick Piggi » Mon, 14 Apr 2003 14:00:15



>I'm e*d about the new I/O scheduler (proposed?) in the 2.5.x kernel, but
>I have to admit to a considerable amount of ignorance of its actual
>behavior.  Thus, if it already does what I'm talking about, please feel free
>to ignore this post.  :)

>Any good SCSI drive knows the physical geometry of the disk and can
>therefore optimally schedule reads and writes.  Although necessary features,
>like read queueing, are also available in the current SATA spec, I'm not
>sure most drives will implement it, at least not very well.

The "continuous" nature of drive addressing means that the kernel
can do a fine job seek-wise. Due to write caches and read track
buffers, rotational scheduling (which could be done if we knew
geometry) would provide too little gain for the complexity. I would
say that for most workloads you wouldn't see any difference. (IMO)

Quote:

>So, what if one were to write a program which would perform a bunch of
>seek-time tests to estimate an IDE disk's physical geometry?

Yes, something like this has been done.

Quote:>It could then
>make that information available to the kernel to use to reorder accesses
>more optimally.  Additionally, discrepancies from expected seek times could
>be logged in the kernel and used to further improve efficiency over time.

The benefit I see is knowing the seek time itself (not geometry), which
can be used to tune the IO scheduler. This is something that I'll
probably need to do (in kernel) in order to get my IO scheduler in 2.6,
as it probably (not tested yet) has bad failure cases on high seek time
devices like CDROMs.

Quote:

>If it were good enough, many of the advantages of using SCSI disks would
>become less significant.

I'm not sure that this is among SCSI's big advantages. I know some
SCSI disks have farness/starvation problems with big reorder windows.

Quote:

>Ideas?

It is worth looking into I think. I will be testing something like it
for AS but in kernel not userspace. I don't think it would be very
useful to help basic head movement optimization, but I would like
someone else to prove me wrong.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by Timothy Mille » Mon, 14 Apr 2003 17:30:11



Quote:> The benefit I see is knowing the seek time itself (not geometry), which
> can be used to tune the IO scheduler. This is something that I'll
> probably need to do (in kernel) in order to get my IO scheduler in 2.6,
> as it probably (not tested yet) has bad failure cases on high seek time
> devices like CDROMs.

Well, that IS the heart of the matter, really.  Detecting geometry was only
a means to the end of predicting seek time and rotational latency.  If you
could magically predict the seek time between any two accesses, then you
could sort your queue optimally.  What would be able to do that?  A neural
net?  :)  What would be able to do that without a lot of training time?

Personally, I've been e*d about AS, and I would hate to see it not get
in.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by Alan Co » Mon, 14 Apr 2003 17:30:12



Quote:> Any good SCSI drive knows the physical geometry of the disk and can
> therefore optimally schedule reads and writes.  Although necessary features,
> like read queueing, are also available in the current SATA spec, I'm not
> sure most drives will implement it, at least not very well.

Some of them are in recent PATA and Jens Axboe implemented the TCQ for
IDE, but its all a bit limited right now

Quote:> So, what if one were to write a program which would perform a bunch of
> seek-time tests to estimate an IDE disk's physical geometry?  It could then
> make that information available to the kernel to use to reorder accesses
> more optimally.

Its a common misconception that a disk looks something like it did 15
years ago. Your ATA disk is basically an entire standalone computer
running a small OS. The physical disk layout does not divide neatly
into equal sized cylinders and some blocks may even be in suprising
places due to bad block sparing or anything else the drive manufacturer
felt appropriate.

The drive firmware will look after a lot of the optimising for you,
and once it gets TCQ it will probably get you all you want from SCSI
with SATA. Until then playing games with it isnt likely to help - feed
IDE disks large, sequential I/O as much as possible and they'll deliver
you very nice numbers.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by John Bradfor » Mon, 14 Apr 2003 18:20:09


Quote:> > So, what if one were to write a program which would perform a bunch of
> > seek-time tests to estimate an IDE disk's physical geometry?  It could then
> > make that information available to the kernel to use to reorder accesses
> > more optimally.

> Its a common misconception that a disk looks something like it did 15
> years ago. Your ATA disk is basically an entire standalone computer
> running a small OS. The physical disk layout does not divide neatly
> into equal sized cylinders and some blocks may even be in suprising
> places due to bad block sparing or anything else the drive manufacturer
> felt appropriate.

Is the basic assumption that lower block numbers are generally located
in zones nearer the outside of the disk still true, though?  I.E. do
you know of any disks that 'start from the middle'?  I usually
recommend that people place their swap and /var partitions near the
beginning of the disk, (for a _slight_ improvement), but maybe there
is a good reason not to do this for some disks?

John.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by Chuck Ebber » Mon, 14 Apr 2003 20:10:12



>> Any good SCSI drive knows the physical geometry of the disk and can
>> therefore optimally schedule reads and writes.  Although necessary features,
>> like read queueing, are also available in the current SATA spec, I'm not
>> sure most drives will implement it, at least not very well.

> The "continuous" nature of drive addressing means that the kernel
> can do a fine job seek-wise. Due to write caches and read track
> buffers, rotational scheduling (which could be done if we knew
> geometry) would provide too little gain for the complexity. I would
> say that for most workloads you wouldn't see any difference. (IMO)

  OTOH you can come up with scenarios like, say, a DBMS doing 16K page
aligned IO to raw devices where you might see big gains from making sure
those 16K chunks didn't cross a physical cylinder boundary.

--
 Chuck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by Dr. David Alan Gilber » Mon, 14 Apr 2003 20:30:22



Quote:>   OTOH you can come up with scenarios like, say, a DBMS doing 16K page
> aligned IO to raw devices where you might see big gains from making sure
> those 16K chunks didn't cross a physical cylinder boundary.

Maybe true; but figuring out where the drive really puts your sectors
these days ain't that easy; what with remapping and multiple different
densities on the platter.

Now given these discs have processors on board isn't it about time
someone improved the disc interface standards to push some of the
intelligence drivewards?  I guess with enough intelligence the drive
could do free block allocation and could do things like copying blocks
around for you.

Dave
 ---------------- Have a happy GNU millennium! ----------------------  
/ Dr. David Alan Gilbert    | Running GNU/Linux on Alpha,68K| Happy  \

 \ _________________________|_____ http://www.treblig.org   |_______/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by Lars Marowsky-Bre » Mon, 14 Apr 2003 20:50:17


On 2003-04-13T19:24:05,

Quote:> Now given these discs have processors on board isn't it about time
> someone improved the disc interface standards to push some of the
> intelligence drivewards?  I guess with enough intelligence the drive
> could do free block allocation and could do things like copying blocks
> around for you.

Ah, you have reinvented SCSI (which can copy without involving the host...),
or reinvented the Object Based Storage (see Lustre).

Sincerely,

--
SuSE Labs - Research & Development, SuSE Linux AG

"If anything can go wrong, it will." "Chance favors the prepared (mind)."
  -- Capt. Edward A. Murphy            -- Louis Pasteur
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by Dr. David Alan Gilber » Mon, 14 Apr 2003 21:00:13



Quote:

> Ah, you have reinvented SCSI (which can copy without involving the host...),
> or reinvented the Object Based Storage (see Lustre).

Gee and I just thought I was being mad.....

Dave
 ---------------- Have a happy GNU millennium! ----------------------  
/ Dr. David Alan Gilbert    | Running GNU/Linux on Alpha,68K| Happy  \

 \ _________________________|_____ http://www.treblig.org   |_______/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by Chuck Ebber » Tue, 15 Apr 2003 00:20:18



> Object Based Storage (see Lustre).

  Thanks, I was trying to remember where I'd seen that.

  Is anyone actually making such things for sale?

--
 Chuck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by Alan Co » Tue, 15 Apr 2003 01:20:10



Quote:>   OTOH you can come up with scenarios like, say, a DBMS doing 16K page
> aligned IO to raw devices where you might see big gains from making sure
> those 16K chunks didn't cross a physical cylinder boundary.

You couldn't even tell where such boundaries exist, or what the real
block size of the underlying media is. Cyliners are all different sizes.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by Alan Co » Tue, 15 Apr 2003 01:20:13



Quote:> Now given these discs have processors on board isn't it about time
> someone improved the disc interface standards to push some of the
> intelligence drivewards?  I guess with enough intelligence the drive
> could do free block allocation and could do things like copying blocks
> around for you.

I wish it would. Most of the research and stuff so far has either put
the file system into the disk firmware (upgrade hell). Having a disk
which talked entirely about

        read(handle,offset, length)
        write(handle, offset, length)
        alloc(handle, near_handle, length, otherhints...)

might well work out rather better. It also allows the disk to do fairly
major relayout of data as it learns usage.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by Andreas Dilge » Tue, 15 Apr 2003 01:50:10




> > Object Based Storage (see Lustre).

>   Thanks, I was trying to remember where I'd seen that.

>   Is anyone actually making such things for sale?

Yes, there is a 3rd party vendor which has already sold a bunch of
Object Storage Targets (OSTs) to LLNL for the MCR cluster, see:

        http://www.top500.org/top5/2002/11/five/
        http://www.llnl.gov/linux/mcr/
        http://www.bluearc.com/news/press_releases/pr_mcr_121102.shtml

These are not the "OST-on-a-disk" paradigm that we first worked on with
Seagate, but rather large NAS/NFS storage servers that also implement
the Lustre network protocol.  We are also working with other vendors to
implement Linux-based OST targets (I'm not sure whether I can reveal names
or not) for even larger clusters.

Maybe if Lustre becomes popular enough, we will see Lustre implemented on
single disks.  There is an object-based storage group with the SCSI T10
committee, but so far their protocol is mostly unusable for Lustre.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Benefits from computing physical IDE disk geometry?

Post by Andreas Dilge » Tue, 15 Apr 2003 02:30:13




> > Now given these discs have processors on board isn't it about time
> > someone improved the disc interface standards to push some of the
> > intelligence drivewards?  I guess with enough intelligence the drive
> > could do free block allocation and could do things like copying blocks
> > around for you.

> I wish it would. Most of the research and stuff so far has either put
> the file system into the disk firmware (upgrade hell). Having a disk
> which talked entirely about

>    read(handle,offset, length)
>    write(handle, offset, length)
>    alloc(handle, near_handle, length, otherhints...)

> might well work out rather better.

This is essentially what the Lustre Object Storage Target (OST) protocol
looks like.  The client talks to the OST with "object IDs" and does simple
create/destroy/getattr/setattr operations on the objid.

The data I/O protocol (bulk read/write) can do scatter/gather vector I/O
on one or more objects at a time using objid/offset/range triplets, and
the internal data representation is totally opaque to the client (i.e. no
block numbers are passed around in the API).

One thing that is totally missing from the Linux client-side is the ability
to use a "copy" syscall to copy objects directly between OSTs instead of
having to go through the client.

Quote:> It also allows the disk to do fairly major relayout of data as it learns
> usage.

Yes, among other things.  We can do stacking of drivers (e.g. RAID, snapshot,
migration, read caching, etc) without having to change the protocol.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. Disk Geometry on Second IDE Disk

<HTML>
<BR>>I have two 1.6G hard disks. I can use both of them in win95. Linux
has
<BR>>no problem to recognize the first one and the 2nd one it returns a
disk
<BR>>gemotry error. The error message is something like " # of head > 64.
<BR>>disk geometry error". I tried to manually set the disk geometry(CHS)
in
<BR>>LILO. It still doesn't work.
<BR>>

<P>&nbsp; I have a similar problem with mounting /dev/hdc.&nbsp; For some
reason
<BR>&nbsp; linux detects the "true" geometry, not that from the BIOS.&nbsp;
My problem
<BR>&nbsp; is too many cylinders.&nbsp; I am going to try to use /etc/disktab
to remedy
<BR>&nbsp; the problem,&nbsp; (see <A HREF="http://ftp.yggdrasil.com/bible/lilo/user/node47.html">http://ftp.yggdrasil.com/bible/lilo/user/node50.html</A>)
<BR>&nbsp; but I don't know which device number to use.&nbsp; Can anyone
help me out
<BR>&nbsp; with this (0x500 is my guess...)?

<P>&nbsp; Bo Green</HTML>

2. External ISDN TA Slow under 2.2.14

3. Timing problems??

4. 2.2.0pre5/6 IDE disk geometry detection problem

5. gnome_execute_async (fork)

6. disk geometry of an IDE drive not/wrong detected

7. CTM missing 1039

8. IDE disk geometry not recognised

9. IDE Hard disk geometry problem in 2.4.19 / 2.4.20pre7

10. IDE & Geometry & Portability of disks between controllers

11. 4.1.1 sees IBM 20Gb IDE disk geometry wrong.

12. How do I set the physical geometry?