[mythtv-users] OT: Filesystems for recordings

[Chris Pinkham]

* On Tue Nov 28, 2006 at 01:26:38PM -0800, Bruce Markey wrote:
> Yes. Chris Pinkham is finishing this up and I may be speaking
> out of turn by mentioning this but I wanted to give you a

You're fine.  I didn't want to talk about it much earlier because
I wasn't able to give any kind of definitive timeline.  Now
that it looks like it's commit-quality, I'm fine with recommending
it more.

> soon. A couple of are testing it right now and it works well
> enough that I'm running it on my production systems, as is
> Chris, as well as on some test environments. I'm now trying
> to do stupid things to try to break it.

Seems to be working fine for me.  Janne mentioned that it looked like
some of his recordings weren't balanced properly, but I haven't seen
any unexplainable situations so far.  The latest patch has more
debug info in it to allow seeing why a specific directory in the
group was chosen.

> > Is there a write up on how this is going to be used.
> 
> Chris does have info for testing and a commit message in
> progress but I'll leave to him if he wants to give that
> out at some point.

Really brief (compared to my draft commit message) description is:

Storage Groups will let you create multiple directories to be used for
recordings.  On the Scheduled Recording editor page, you assign a
scheduled recording to a Storage Group.  A Storage Group can have one
directory or many directories.  By default, all recordings go into
the 'Default' Storage Group which is composed of the value that used
to be stored in the RecordFilePrefix setting in the database.  It is
preferable to have each directory in a Storage Group be on a separate
filesystem to spread out I/O load during file operations.

The current load-balancing preferences in order are as follows:

  - Local filesystems over remote
  - Less-busy (less weight) over more-busy (more weight)
  - More Free Space over Less Free Space

The preferences are based on weight.  Each directory/filesystem is
weighted based on what actions are currently going on on that filesystem,
such as recordings, playback, commercial flagging, and transcoding.
The logic will prefer to put 2 recordings onto a local filesystem before
expanding and using a remote filesystem.

> > to get better throughput but still see everything normally in the front 
> > end. What is the best way to know when this gets pushed to the svn? 
> 
> Watch the commits list.

Yes. :)  I think this will be committed in the next couple days unless
something major pops up.  I'm running the latest patch on my production
system in full debug mode so I can look for anything out of the ordinary
during tonight's fairly full recording schedule.

--
Chris