[mythtv-users] How to add more recording disk space: Christmas
is coming !
bjm at lvcm.com
Sat Dec 18 18:30:30 UTC 2004
Brad Templeton wrote:
> On Thu, Dec 16, 2004 at 09:23:21AM -0800, Bruce Markey wrote:
>>No one punted, it's more like no one suited up. This was one
>>of my first suggestions ever on this list:
> Wasn't trying to be critical, you can't do all at once.
Oh, I didn't take it as criticism, it's probably just a different
interpretation of "punt". I think of punt as meaning a conscious
triage decision that something should not be done. I don't think
there is any such decision but it's just that no one that has
needed this has done it. I shouldn't be difficult. If I'd needed
this I would have done it long ago.
>>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.
> I don't know if there is that much harm in putting them in the DB, it
> just means if you move a file from one fs to another you have to tell
> the system.
That was kind of short hand for some earlier issues. Think of
a webserver. There is a doc root of, say, /var/www . for a URL
of http://hostname/index.html , the server goes and finds the file /var/www/index.html . The client doesn't/shouldn't need to know
or pass the local path to the server. In fact, if full paths
could be used, something acting as a client could make a request
for /etc/passwd . This had been a potential issue for myth a long
time ago. So all I meant was that a frontend asking for playback
or the master asking a slave should only ask for the file for
chanid 1003 that started at 20040907123000 . Where this file
is should only be the business of the local server and the
exact location should not be stored and passed around.
> I would really love a different file naming scheme anyway, including
> elements from the program name etc.
Ah, that's the other side of the "/". As far as the server and
interface is concerned, the filename are internal data and
don't need to be human readable. Someone already wrote a script
to create symlinks with readable names that point to the actual
>>- Even better, the free space could be checked for each dir then
>>it could use the one with the most free space.
> Related to this is the idea of classes of programs which have pools
> of space. Like Tivo suggestions which use spare space, and are immediately
> deleted for a real recording.
> You can relate this to filesystems, that one class of program goes
> on the keep-forever disk, shorter term stuff etc.
I don't think there is any need to have separate physical spaces
to have this kind of policy (in fact you'd be better off considering
the total space). When cpinkham added auto expire, he deliberately
designed it to allow any kind of policy to be added easily and
included the most obvious "Oldest Show First" as an example.
Today, if you go to Setup->TV Settings->General page 3, this is
still the only option. A method could be added to remove all
of these before any these but no one has seen fit to do this
yet (and no one has punted =).
>>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.
> Actually, since video is typically no more than a few megabytes
> per second, which is well within the capacity of modern disks, I
> would let the writing task be left to the filesys.
As opposed to...? I'm not talking about writing to raw partitions.
The point is that the brand name of the filesystem is not the issue.
The partition layout is the issue. Any filesystem that will pretty
much write the video file to contiguous blocks will be a magnitude
faster than needed. However, if things are scattered about and
laid out in a way that causes a lot of head thrashing, latency
can go up and throughput can go down significantly.
For hypothetical example. Say, we have a 7200RPM disk that has
an average of about 1MB worth of sectors per cylinder, an average
seek time of ~20ms and track to track seeks of ~10ms.
Let's say we use this disk by itself for a small news server with
no binary groups and the average file size is 10k (which is
probably high) and it writes randomly to the directories for
newsgroups scattered across the disk (which doesn't account for
the elevator algorithm). At 20ms avg seek, it can only move to
50 locations per second and at 10k per write that's only ~500kb
Now let's copy a video file to the same disk with unlimited
bandwidth up to the disk itself. At 7200RPM the disk spins 120
time per second. If it did nothing but write, 120 cyl would pass
under the head. If it did nothing but seek it would move track to
track 100 times. Therefore it could seek and write something near
60 cyl per second for about 60MB per sec.
Notice that the difference between 500k and 60MB isn't 20% or
double but 120 fold(!). This is not intended to demonstrate any
real world performance but to illustrate that it isn't the
bullet items on the box for the disk or the brand name of the
filesystem used but it's the usage pattern that has the biggest
impact on the performance of the disk.
Because there is such a wide variation in throughput, there are
a lot of tricks that can be done to improve performance (or fault
tolerance) for specific application or types of applications.
Database servers have different optimizations than home directories
or news servers. The optimal performance for video files is 1)
position heads 2) let it rip ;-). Any form of parity, journaling,
certainly striping(!), etc. all hinder performance, not help it.
People often take it at face value that RAID is good without
looking at what's really going on. For myth, 3.6GB/hr files are
only 1mb/s so there will be more than enough throughput no matter
how inappropriate the filesystem features are.
Here's where I think many people run into performance problems
and trigger endless debate over which brand of filesystem is best.
It has little to do with the filesystems but is in the partitioning.
Someone gets a big disk to store video and only wants to have this
one disk in the machine. They may partition it something like this:
|root (/var)|swap|video |
L D VV
The problem here is that the "L"og files and "D"atabase files are
on the same physical disk as the "V"ideo files. If there is any
database activity while a recording is in progress, the heads need
to seek to the DB files and append to the log. However, there is
new video data arriving all the time so the heads have to swing
over to append to the video file, swing back to continue with the
db access, and so on.
Again, this thrashing isn't 20% slower or twice as slow, it's a
magnitude slower. The normal throughput should still allow the
disk to keep up but under extreme conditions it could become Lucy
in the chocolate factory. Even while the disk is keeping up, there
will be higher latency. If the scheduler takes a second or two to
run, it may take several seconds while a recording is in progress.
Other actions in the frontend that need to access the DB or other
system files may be less responsive.
A better approach is the use a small disk for the system partitions
(I use some old 4GB and 13GB disk for this on my system) and
partition the big disk for video only with no other partitions, not
even swap space.
Here, if there is DB activity while a recording is in progress, the
heads on the system disk still move between the DB files and logs
but it is the same whether there is a recording or not. Also, the
disk's cache can be more effective if there isn't video data passing
through replacing cached data from system files. For the video
partition, the heads never have to move and writing out a recording
is unaffected by any flurry of activity on the other disk.
Notice that in the first example, thrashing will take place no
matter what the brand name of the filesystem is for the video
partition. In the second, the heads will generally remain tranquil
no matter which filesystem type is used (except that some filesystem
features designed for other types of apps may cause more unnecessary
While people seem to enjoy promoting their fs of choice (most
likely chosen by irrelevant criteria ;-), what it comes down to is
that it doesn't matter. If video files are written to a dedicated
spindle, the disk will perform well. If the heads for the video
partition have to thrash between multiple partitions, the disk
will perform poorly.
If I added a second video disk, I'd want to mount it separately
and be free to move files between the two and be able to clear
one out completely in order to re-format, remove or replace the
disk. I wouldn't want the filesystems for the two disks tied
together especially knowing that the reasons for intertwining
the disks actually hurt performance rather than help it for this
type of application.
More information about the mythtv-users