[mythtv-users] OT: best way to connect IDE harddrives and dvd

[Matt Mossholder]

Consolidating replies to Brian and Chris together below... 

	
On Mon, 2006-09-18 at 09:29 -0600, Brian Wood wrote:
> On Sep 18, 2006, at 12:53 AM, chris at cpr.homelinux.net wrote:

> > In the long run, however, there are three points that make all that
> > "optimizing" a moot point:
> >
> > (1) Most drives and/or drivers do command buffering and optimize
> > based on real-time requirements.  For example, if the drive heads
> > are on an inner track and there are 10 requests pending (including
> > a read from the swap file on the outer track), the swap access may
> > be the last task executed even if it was the second task in the
> > queue because *on average* the best performance occurs when the
> > heads don't change direction.

	Yes, but how often do you read just one block from swap?  It is the
sequential access that counts. The command buffering and optimization
would help overall performance, including the performance of swap. There
may be an increased latency for starting to send data, but the overall
speed should be higher since the sectors are more likely to be retrieved
without interruption.

> > (2) Unlike the ST-506 days, the CHS values reported by IDE drives
> > are totally fake.  Telling fdisk that you want a partition to be in
> > the middle of the drive doesn't actually mean it will be on the
> > middle cylinder.

	This is actually untrue. Lower numbered LBA sectors will always be at
the edge of the disk, unless they have been remapped, as you have
mentioned in point 3. You may not be able to say what exact cylinders on
the disk the partition will land on, but you can have things be in the
generally correct location (i.e. start, middle, end)

> > (3) Drives do sector-substitution without your knowledge.  Three
> > sequential LBA blocks are not always going to be in sequential
> > sectors on the drive.

	That doesn't negate the advantage to the rest of the sectors. With
optimization, it should take care of getting the  sectors that are
adjacent, and get the stragglers separately.

> All true, and (4) Linux will do its own smart caching of oft-accessed  
> info in any case.
> 
	I don't believe Linux caches access to swap. That would be counter
productive (i.e.  if it was going to live in the buffer cache, why swap
it to disk in the first place? You wouldn't be regaining any memory that
way.)

> These days even assembly code is so far removed from the physical  
> platters that trying to optimize based on drive geometry etc. is  
> pretty much wasted effort, and may actually work against you.
> 
> BTW - wasn't that ST-502 not 506? or is my early-onset Alzhiemer's  
> kicking in ? I assume you meant the interface with the two separate  
> cables for control and data, sometimes mistakenly called "MFM", which  
> is an encoding method not an interface.

I it was ST-506...  http://en.wikipedia.org/wiki/ST-506


Also, a big caveat to all the stuff above: It goes out the window with
more complex configurations like hardware RAID, Fibre Channel, etc.,
where you may go through multiple LBA conversions before you hit the
hardware.


		--Matt