Matthew Daubenspeck wrote:
>> What kind of machine hardware are we talking about here? I have a fairly
> modest system (1.8Ghz, AMD64 processor) running a software raid5 system
> with no issues whatsoever. I am using a standard SATA 3.0 4 port card
> with only 3 drives, and haven't noticed any issues even when recording 4
> programs and watching another simultaneously. It uses ext3 as well.
> Could your bottleneck be somewhere else?
Oh, everything works just fine if the machine is idle other than mythtv
- the problem happens at 2AM when I've got cron jobs running, or if I do
IO-intensive tasks (such as copying 150GB of video onto the myth video
partition - even with ionice -c 3 nice -n 20).
I agree with the comment that it would be nice if mythtv buffered data
better or didn't sync everything out to disk (hmm, sounds like something
a simple patch could take care of - can anybody think of a downside to
this?).
I'm running 3 150MB/s SATA 7200RPM drives on RAID 5. The PC is an
Athlon64 3200 running 64-bit, with 2GB RAM. Should be plenty for myth.
My myth video is on its own partition, so in general at the ext3 level
it probably shouldn't be in contention with other activity on the RAID.
However, I don't know how well those priorities get tracked from
userland down through the multiple layers of hardware abstraction. Now,
I could see there being filesystem-related problems when I was copying
lots of data on my video partition, since that was on the same filesystem.
As far as xfs goes - my understanding is that open files get zeroed out
if the filesystem is dirty upon fsck. This is a security feature to
prevent misallocated sectors from becoming readable by users other than
the ones who wrote the data to disk in the first place. If somebody
knows a whole lot better than me please point me at some references on
this behavior, but I'd rather not lose entire shows if I lose power
while they're being recorded.