[mythtv-users] Various MythTV-related adventures

[Yeechang Lee]

I've recently made some interesting and more or less MythTV-related
discoveries.

The backend server mentioned in my signature runs Fedora Core 6 with
the 2.6.20-1.2962 kernel. It is the master MythTV backend, mythconverg
database host, software RAID 6 array that acts as one of my three
recording drives, and a VMware Server virtual machine I use as my
normal user environment.[1] I don't use 2.6.22 because for some reason
I don't recall mdadm wasn't able to start its 16-drive array. The
drives hang off a HighPoint RocketRAID 2240 acting purely as a SATA
controller.[2]

I decided to try out HighPoint's proprietary hptmv6 driver in place of
the Linux kernel's sata_mv driver. I expected that I would still be
able to use software RAID. Since it is only available for the
2.6.18-1.2798 kernel (always a bane of binary-only drivers) for Fedora
Core 6 I downgraded to it, then copied hptmv6.ko to the appropriate
place in /lib/modules.

Rebooting brought issues. Both sata_mv and hptmv6 would load, causing
the boot process to hang, even when booting into single-user
mode. Using the magic SysRq to kill the boot process would get me to a
root prompt but with a read-only filesystem and a mount that (thanks
to the preexisting /etc/mtab) stubbornly refused all attempts to let
me remount the root partition as read-write.

Since I couldn't find my Fedora Core 6 install DVD to use as a rescue
disk I burned first the UltimateBootCD (which turned out to be more
DOS/Windows-oriented), then SystemRescueCd. Although SystemRescueCd
claimed JFS support, I was unable to mount the root partition. I
finally realized that it simply needed fsck first.

The next few boot cycles were spent repeating the above steps. I'd try
various ways of disabling sata_mv from loading, including 'alias
sata_mv off', 'blacklist sata_mv', and even moving/renaming
sata_mv.ko. No luck; it kept reappearing.

I finally played it smart by booting with just sata_mv, then shutting
down mythbackend and autofs, then 'mdadm --stop /dev/md0', then 'rmmod
sata_mv', then 'modprobe hptmv6'. It booted fine, and said though
dmesg it'd found 16 devices, but /dev/sd[b-q] weren't
there. Apparently, I'd have to go into the controller's BIOS setup and
export each drive as a sigle JBOD array for it to appear. I'm not sure
whether this would require erasing my software RAID array, which of
course was not desired.

In any case, another issue cropped up that prevented further pursuit
of the idea. I noticed that upcoming over-the-air recordings in
mythfrontend were marked as unavailable. The server's mythbackend is the one
set up to talk to my HDHomerun, and it was having trouble doing
so. Sometimes 'ping hdhomerun' would work, and sometimes
not. Sometimes 'hdhomerun_config discover' would work, and sometimes
not. These were issues I'd never faced in a year and a half of using
the HDHomeRun, which has always been a refreshingly install-and-forget
device.

Given I was seeing some odd networking issues with the VMware VM
(which bridges to the physical server's networking card), I figured it
must be something to do with the 2.6.18 kernel. Since I was already
again swapping kernels I figured I'd also try the 2.6.22.14-72 kernel,
the most recent one before Fedora Core 6 hit end of life. No luck;
only five or six of my 16 RAID drives appeared in /dev. So back to
2.6.20-1.2962 I went. Here I am, once again with a fully-functioning
MythTV setup that's, well, exactly the same as it was this time
yesterday.

Through all this my frontend/slave backend was plugging away. In fact,
I rebooted the master backend server midway through a recording the
slave backend was making to its own RAID array. I already knew slave
backends continue recording if the master backend stops and they still
have access to the recording drive being used
(<URL:http://www.gossamer-threads.com/lists/mythtv/users/308094#308094>)
--they just can't start new recorings--but I hadn't realized that they
could do so even if the database itself is temporarily
inaccessible.

Unanswered questions:

* Would exporting each drive as a separate JBOD drive via the
  HighPoint RAID BIOS setup have erased the software RAID array?
* Why couldn't I prevent sata_mv from loading no matter what I tried?
* Why did 2.6.18-1.2798 have networking issues with my HDHomeRun (and,
  as noted, perhaps in general as well)?
* Why was 2.6.22.14-72's sata_mv not able to see all of the drives on
  the controller card?
* Just where did/does my slave backend store the seektable data while
  the database is down? The recording appears complete, with proper
  commflagging. Is it that the commflag job was able to sort of ex
  post facto fix up any data in the seektable lost while the database
  was down?
* I use CentOS 5 everywhere but the Fedora Core 6-running server, for
  historical reasons. I know MythTV works fine on CentOS, of course,
  but given the above I'm now reluctant to upgrade the FC6 server to
  CentOS 5 (beyond the inherent hassle involved) because I can't be
  sure whether CentOS would be able to see the RAID drives. Possible
  solution: Boot with the CentOS 5 installation disk in rescue mode
  and see if the drives are visible and I can assemble the RAID.

[1] Only recently migrated from a seven years-old separate physical
server whose power supply died the moment I finally switched it off. I
really like the idea of decoupling my work environment--the place I
read mail and netnews, and connect to all my other boxes, all via GNU
screen--from any physical server, so I'll be able to easily migrate it
to any faster servers I later possess. Also, if the server it runs on
now is disabled for a while I could always run the VM on my
frontend/slave backend. Using CentOS means it'll have software updates
through 2014.

[2] If, as mentioned in another message, I ever spring for more
storage, I've thought of getting some sort of external SATA
enclosure(s) and connecting it with InfiniBand/eSATA cables to another
controller--whether second RocketRAID 2240 or another--plugged into
the second PCI-X slot in the server. Suggestions on pre-built
enclosures (I can handle installing drives, but not much more) and
controller cards? I'd want at least eight drives, preferably 16-20,
and could use two enclosures.

-- 
Frontend:		P4 3.0GHz, 1.5TB software RAID 5 array
Backend:		Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs:		Four high-definition over FireWire/OTA
Accessories:		47" 1080p LCD, 5.1 digital, and MX-600