[mythtv] [mythtv-commits] mythtv commit: r21225 - in trunk/mythtv by cpinkham

[Chris Pinkham]

* On Fri Aug 14, 2009 at 03:01:03AM -0400, f-myth-users at media.mit.edu wrote:
>     > This patch also does 2 things regarding the default value of the
>     > StorageScheduler setting:
> 
>     > 1) The default method on the setup screen is now 'Balanced Free Space'.
>     > 2) A DB upgrade inserts a setting into the database to set the method
>     >    to 'Combination' so that users upgrading from previous versions will
>     >    see the same scheduling logic they have been seeing.  Users can
>     >    change the value in mythtv-setup anytime and restart the master
>     >    backend for the new value to take effect.
> 
> I hesitate to ask, but...  what happens if someone updates from a Myth
> that dates from before storage groups?  I'm guessing that various

Actually for now, the same thing will happen if a user upgrades from a previous
version or if they install fresh.  This is because of the way that our DB
upgrade code works.  The DB upgrade has a schema definition defined to be
a certain DB version, then we make updates to that and bump the version number
up.  Every not so often (ie, every few years maybe), we upgrade that base
schema definition to a newer version.  Until the schema is upgraded past
the version where I added this setting to the settings table, then that means
all users will get 'Combination' by default which retains 0.21 functionality.

The 'balance free space' vs 'balance I/O' difference isn't as big as it
seems.  The original I/O balancing code still would balance by disk space
when I/O weights were equal.  A new single recording starting up would go
onto the filesystem with the most free space.  It's when the second
recording goes up that the I/O balancing would send it to another filesystem,
but as long as that first filesystem had more free space, it would always
get the recording if there was only one recording going on (unless there was
over lap with a prior recording).

> I'm also guessing that, even if it's possible to detect this, adding
> the necessary hair to dbcheck probably isn't worth the potential for

I debated what to do about this, but chose to err on the side of not changing
things for existing users.  <farfetched-example> If balancing I/O has been
helping users who don't let their hard drives fill up, then switching them to
balancing free space could start causing issues if all the sudden they have 5
HD recordings going to the shiney new USB drive they attached to their fileserver.
</farfetched-example> :)

--
Chris