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 _______________________________________________ mythtv-users mailing list [EMAIL PROTECTED] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
