[mythtv] Possible Future Option?

Matt Zimmerman mythtv-dev@snowman.net
Sat, 30 Nov 2002 11:44:05 -0500


On Sat, Nov 30, 2002 at 12:45:38AM -0800, Bruce Markey wrote:

> Matt Zimmerman wrote:
> >I understood fine, but I cannot think of a realistic situation where
> >would be useful to me.  Why would you want to place different recordings
> >under different paths?
> 
> Matt, first off, thank you for your efforts on this project.  I first
> installed from your Debian packages to check things out before compiling
> from source. It was very reassuring to have everything configured
> correctly for me and to see it work on the first try.

Thanks, it's always good to hear about successful installations.  In most
cases, those without problems don't provide feedback.

> There may never be a realistic situation where storing files in different
> directories would be useful to you and I believe that there are certainly
> bigger fish to fry. However, I too thought this might be useful even
> before seeing Jeremy's post.
> 
> First, I'm using a machine with a 30GB disk. Root and swap are at the
> beginning then a large partition where I put the video files. I want more
> space so I'll probably get a 60-100 Gig disk. I may not be able to stripe
> the mismatched disks together and may not want to even if I could. If I
> can only write to one dir on the new disk I can't take advantage of the
> free space on the current disk. Myth could choose to start a new recording
> in the dir with the most free space so the user doesn't need to worry
> about it.

Simple concatenation (e.g., RAID-linear or EVMS drivelinking) has no problem
with differently-sized disks, and lets you place one large filesystem on the
volume.  If the goal is to pool your available storage, then a lower-level
solution is a superior option, I think.  It avoids the need for a decision
about which filesystem to use, and allows for files which are larger than
would fit on one disk.

> Next, with multiple tuners, the performance might be better if each file
> is streamed to one dedicated disk. The fastest way to write a large
> continuos files is to position the disk head and let it rip with the heads
> only making track to track seeks at the end of each cylinder. Any RAID
> scheme would cause more head movement for this specific case even though
> RAID is much better in typical cases of random reads and writes. Again,
> myth could choose the dir with the most free space that is not already
> being used for another recording.

This is an interesting idea.  I would like to see how this works out in
practice as far as throughput.  A smart driver will merge the requests for
sequential data into a single request sent to the controller, even if the
data is destined for discontiguous userland buffers (scatter/gather).  I
know that Linux SCSI drivers will do this (indeed, a decent SCSI controller
will do this in hardware), but I'm not sure about the IDE subsystem.  If it
can efficiently do scatter/gather I/O, I would expect performance to be
nearly equivalent in both cases, since the random-order requests for
contiguous blocks would be merged into one big sequential request per disk.

I think this probably comes down more to using a filesystem which is tuned
(or tunable) for large, contiguous file allocation.  I believe XFS was
designed with this in mind.

-- 
 - mdz