[mythtv-users] How to add more recording disk space: Christmas is coming !

Bruce Markey bjm at lvcm.com
Thu Dec 16 17:23:21 UTC 2004


Brad Templeton wrote:
...
> Myth is not great at this.  I symphathise with the need to punt things,
> and so they punted this problem to the lvm system that can be found
> in most modern linux kernels.   You need to have it or install it.

No one punted, it's more like no one suited up. This was one
of my first suggestions ever on this list:

http://mythtv.org/pipermail/mythtv-dev/2002-November/001987.html

I agree with Terry that the 'RecordFilePrefix' could be a regular
colon separated path list. To open a file for read, it would just
need to opendir on each until a match is found. Only the local
backend needs to know the full path to a file (as it should be)
so the full paths don't need to be passed around ar stored in the
DB. For write, there are several things that could be done.

- First, cpinkham already added code so that a backend with a full
disk will cause another backend with space available to be used.
This could be modified for a tuner with more than one dir to use
the second if the first is full.

- Even better, the free space could be checked for each dir then
it could use the one with the most free space.

- For a multi-tuner, multi-disk system, it would even be a good
idea for the encoder to write a smal lock file with it's endtime
in the dir. Then when selecting a dir, choose one where there isn't
a lock file with a future timestamp, if any. This would allow
multiple recordings to stream to separated dedicated disks with
as little fragmentation as possible.

This wouldn't be very hard but I've never pursued it because I
don't need it at this point. However, it looks like you'll need
more disks ;-) and understand that LVM isn't the right answer.
This would be familiar Unix system coding and you could add
features in small, low inpact steps. Even the simple step of
splitting and reading from a colon separated path list by itself
would be a good thing. It would at least allow manually mv'ing
files to another disk where the backend can still find then
for playback.

> I think in the long run this is a poor punt because if people did not
> set up their disk with LVM, it's a hard slog to switch things over.
> 
> In addition, LVM won't handle the idea of having some control over what
> disk programs go on, and of storing programs on a network mounted filesystem
> as well as a local one.   This makes some sense.   Also, if you want to
> use hard drives as an archive, you would like to tell it to move files
> to a given filesystem.

Agree with this and more. For me, a key point is that the best
and most efficient way to write out a continuous stream is to
position the heads on a dedicated spindle and let it fly with
the heads only needing to make track to track seeks. RAID
concepts like striping across multiple disk so that several
small files can be written in parallel makes good sense for
home dir fileservers or news servers. However, for this type
of application where large files are streamed, any filesystem
tricks to optimize for other types of applications will under
perform simply having a single partition disk with one video
file being written and no other head movement.

--  bjm


More information about the mythtv-users mailing list