[mythtv-users] Software RAID and ionice

Gene Stapp genestapp at gmail.com
Wed May 23 05:17:31 UTC 2007


I got around this problem by creating a raid0 partition just for myth to use
(and any not very important video) - two 500GB drives do a great job. That
keeps the other raid arrays clear for other uses and for permanent storage
of important video. Raid 5 arrays suck at write operations compared to raid
0s... Also just use xfs with a correctly installed battery backup that can
shut down the system if needed and your filesystem issues would be solved.
I'm thinking your choice of filesystem is causing the issue for the most
part.. I'd like to see to some Bonnie++ tests to see how good the raid is to
begin with.

On 5/22/07, David Rees <drees76 at gmail.com> wrote:
>
> On 5/22/07, Richard Freeman <r-mythtv at thefreemanclan.net> wrote:
> > 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).
>
> You'll find that during these times if you do something as simple as a
> `touch /tmp/testfile && rm /tmp/testfile` that it will take abnormally
> long for that operation to complete.
>
> > 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?).
>
> IIRC, the reason that mythtv syncs data to disk in small chunks is
> that the devs found if you didn't, you'd occasionally end up with bad
> behavior. I'm not sure exactly what the "bad behavior" was, though. It
> should be relatively easy to modify the data writing routines, though.
>
> > 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.
>
> OK, that is good.
>
> >   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.
>
> Yes, it is somewhat baffling that IO on the other partitions is
> heavily affecting IO performance on your myth FS as it seems that you
> have things setup pretty well. Can you get any top, vmstat or iostat
> output from the periods that myth has IOBOUND issues?
>
> > 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.
>
> You definitely will not loose entire shows if power goes out. However,
> you will lose whatever hasn't been flushed to disk and given that myth
> does flush the data out to disk fairly regularly, the amount of data
> loss should be low, I would imagine 30s at the most depending on how
> often xfs flushes the journal.
>
> In addition just opening a file for reading will not induce any data
> loss, you only have the potential for data loss with "dirty data" or
> data that is being written to disk.
>
> -Dave
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20070523/4b2583bf/attachment.htm 


More information about the mythtv-users mailing list