[mythtv-users] Switching backend IDE drives to libata with 2.6.28 kernel

Tom Dexter digitalaudiorock at gmail.com
Mon Jun 1 21:19:29 UTC 2009

On Mon, Jun 1, 2009 at 3:22 PM, belcampo <belcampo at zonnet.nl> wrote:
> Tom Dexter wrote:
>> On Mon, Jun 1, 2009 at 2:23 PM, belcampo <belcampo at zonnet.nl> wrote:
>>> Tom Dexter wrote:
>>>> The one that has be a little concerned is the multiple sector I/O
>>>> hdparm setting (-m) which isn't supported either.  From what I've seen
>>>> so far, libata seems to default this to 8 when the drives max is 16.
>>>> Except for WD drives, I don't see anything in the hdparm man page that
>>>> would lead me to believe that 8 would be better than 16.  As a matter
>>>> of fact, I never even used the -m option in hdparm, as the old driver
>>>> defaulted to 16.
>>>> My backend has two 500GB Seagate IDE drives.  I haven't had a good
>>>> opportunity to get rid of my lvm partition in favor of storage groups.
>>>>  The lvm spans the drive that also has the / partition and the MySQL
>>>> databases.  I know that's not an ideal setup, but adding a drive would
>>>> be nightmarish, and in any case, it currently works fine the way it
>>>> is.  I can record three HD shows at once while watching another
>>>> previously recorded program with no problems at all.
>>>> I really don't think I can afford to loose even a hint of disk
>>>> performance on that setup, which is why I started looking so carefully
>>>> at this one.  Any advise would be appreciated.
>>> 3 HD-shows at an unrealistic 33Mb/s calculates to 100Mb/s = 12.5MB/s
>>> Even an average drive from 2-3 years old does ->50MB/s, this is
>>> sequential I
>>> know, but never the less.
>> I agree that overall transfer rates wouldn't be an issue.  But I'm
>> still concerned about the multiple sector I/O setting because of all
>> the concurrent stuff going on including recording, playback, and
>> database reads/writes.  Even with my current setup, if I'm recording
>> three shows and also watching something at the frontend, starting up a
>> few commflagging jobs can cause an occasional IOBOUND error.  That
>> tells me I don't have much room to loose any performance.
> That's probably because of the 'less then optimal' settings for
> buffer-settings in the internal player. Over the years a lot of users where
> suffering from stuttering because of this.
>> Tom

I'm not sure I understand.  First of all, I didn't think there were
any configurable buffer settings to begin with.  Also, the IOBOUND
errors I mentioned are on the backend.  What would that have to do
with the player?


More information about the mythtv-users mailing list