[mythtv-users] Hard disk speed needs for MythTV system

[Itai Tavor]

On Monday, September 22, 2003, at 01:03 PM, Date Stewart wrote:
>
> As with a lot of things in computers, "it all depends...."
>
> With modern interfaces, the usual limiting factor in data transfer is
> how fast bits are going by the read/write head.  That varies with bit
> density on the platters, number of platters, disk size, etc. etc.  Of
> course, you only approach these maximum speeds when you're reading long
> runs on a largely unfragmented disk, but this is typical for video.
>
> A fragmented file can invoke several seeks during a file, drastically
> reducing overall bandwidth.  We did some experiments with 2 and 4 gig
> SCSI disks several years ago, and files with more than 2-3 fragments
> were significantly compromised.  For short (system) files, the limiting
> factor is the finding the right block through the file system, not the
> read bandwidth.  But I digress...  (Is anyone looking at 
> defragmentation
> in Linux and/or video4linux?)
>
> But some generalities: on identical platters, 5400 rpm drives should
> deliver data 54/72ths as fast, about 75%.  Also, since more bits can be
> put on an outer cylinder than an inner cylinder due to the longer
> circumference, the data rate is higher at the beginning of the disk 
> than
> at the end (inner tracks). I Googled a few references: A Western 
> Digital
> 40GB 5400RPM drive was tested at ~30MByte/sec (outer tracks) and ~22
> MB/sec (inner).  A WD 120GB 7200RPM drive was closer to 50 MB/s outer
> and 35 MB/s inner.  (I don't know what the platter densities were.)
>
> However, the implications are pretty clear.  If an older 5400 RPM drive
> will deliver a 22 MB/second worst case stream, it *should* be able to
> record two or three sub-1 MByte/second video capture streams, provided
> the OS isn't doing something really dumb.  You could imagine a
> degenerate case where the file system tries to interleave writing 1
> block of each of 2 video files on opposite ends of the disk,
> guaranteeing a worst case seek per block written. Personally, I know
> nothing about the internals of the Linux file system, but I've been 
> told
> that it optimizes these situations correctly.
>
> One other factoid: it's been years since disks were interleaved.  The
> point of interleave was that in the olden days, the disk controllers
> were not fast enough to read, decode and error check sequential sectors
> on the disk.  Instead, a sector or more would pass under the head,
> unread, while the controller worked.  Therefore the "next" sector was
> not adjacent, but interleaved with one or more sectors that were part 
> of
> a different sequence. As controllers got faster, interleave eventually
> achieved 1:1, i.e. sequential sectors.

Dave, this is an excellent in-depth analysis. Thanks!