[mythtv-users] Storage groups: How to set 'SGweightLocalStarting' to 0?

[Jonathan Larson]

>
> > -----Original Message-----
> > From: mythtv-users-bounces at mythtv.org [mailto:mythtv-users-
> > bounces at mythtv.org] On Behalf Of Brad DerManouelian
> > Sent: Wednesday, October 08, 2008 3:15 PM
> > To: Discussion about mythtv
> > Subject: Re: [mythtv-users] Storage groups: How to set
> > 'SGweightLocalStarting' to 0?
> >
> > On Oct 8, 2008, at 3:07 PM, Jonathan Larson wrote:
> >
> > >> On Oct 8, 2008, at 2:43 PM, Jonathan Larson wrote:
> > >>
> > >>>> I'm new to the SQL CLI, so I didn't even realize there was a
> > >>>> functional difference between "" and NULL. Should the insert
> > >>>> command look like this?:
> > >>>
> > >>> INSERT settings (value, data, hostname) VALUES
> > >>> ("SGweightLocalStarting", 0, NULL);
> > >>
> > >> Since you already have an entry in your database for
> > >> SGweightLocalStarting your command should now look like this:
> > >>
> > >> UPDATE settings SET hostname = NULL WHERE value =
> > >> 'SGweightLocalStarting';
> > >
> > > Thanks Brad,
> > >
> > > I was just asking about the initial INSERT command because I wanted
> > > to add this to the wiki and I wanted to make sure it would be
> > > accurate.
> >
> > Gotcha... yeah, that's right if there is no current entry.
> Personally,
> > I'm a fan of REPLACE INTO which will act as an INSERT of the primary
> > key doesn't exist and an UPDATE if it does. I think this only works
> in
> > mysql, though so I can see why SQL purists would frown on it.
> >
> > Bottom line is yeah, that command is correct. ;)
> >
> > -Brad
> >
>
> So I stopped all the BEs and Fes and added the entry mentioned above to
> the settings table. Then I restarted the main BE and ran a test
> recording.
>
> What I found is that the Null entry did reset the local disk weighting
> to 0, making it equal to the remote disks. In spite of this, the system
> still chose to record to one of the local disks with less free space
> than some of the remote disks. This behavior would seem to be contrary
> to Chris's documentation, though I'm not sure why that happened. Any
> more insight from the experts?
>
> Jon
>
> Log exerpt:
>
> --- GetFilesystemInfos directory list end ---
> 2008-10-09 06:44:29.410 Scheduler: FillDirectoryInfoCache: found 6
> unique filesystems
> 2008-10-09 06:44:29.410 Scheduler: FillRecordingDir: Calculating
> initial FS Weights.
> 2008-10-09 06:44:29.411   AVPC1:/mnt/AVPC1-rec1/recordings is local
> (0). initial dir weight = 0
> 2008-10-09 06:44:29.412   AVPC1:/mnt/AVPC1-rec2/recordings is local
> (0). initial dir weight = 0
> 2008-10-09 06:44:29.413   AVPC1:/mnt/AVPC2-rec1/recordings is remote
> (+0). initial dir weight = 0
> 2008-10-09 06:44:29.414   AVPC1:/mnt/AVPC2-rec2/recordings is remote
> (+0). initial dir weight = 0
> 2008-10-09 06:44:29.415   AVPC1:/mnt/AVPC3-rec1/recordings is remote
> (+0). initial dir weight = 0
> 2008-10-09 06:44:29.417   AVPC1:/mnt/AVPC3-rec2/recordings is remote
> (+0). initial dir weight = 0
> 2008-10-09 06:44:29.417 Scheduler: FillRecordingDir: Adjusting FS
> Weights from inuseprograms.
> 2008-10-09 06:44:29.418 Scheduler: FillRecordingDir: Adjusting FS
> Weights from scheduler.
> --- FillRecordingDir Sorted fsInfoList start ---
> AVPC1:/mnt/AVPC1-rec2/recordings
>     Location    : local
>     weight      : 0
>     free space  : 70778984
>
> AVPC1:/mnt/AVPC1-rec1/recordings
>     Location    : local
>     weight      : 0
>     free space  : 45571944
>
> AVPC1:/mnt/AVPC3-rec2/recordings
>     Location    : remote
>     weight      : 0
>     free space  : 158221328
>
> AVPC1:/mnt/AVPC2-rec1/recordings
>     Location    : remote
>     weight      : 0
>     free space  : 114929048
>
> AVPC1:/mnt/AVPC2-rec2/recordings
>     Location    : remote
>     weight      : 0
>     free space  : 110237936
>
> AVPC1:/mnt/AVPC3-rec1/recordings
>     Location    : remote
>     weight      : 0
>     free space  : 46420320
>
> --- FillRecordingDir Sorted fsInfoList end ---
> 2008-10-09 06:44:29.430 'SGtest' will record in '/mnt/AVPC1-
> rec2/recordings' which has 69120 MiB free. This recording could use a
> max of 72 MiB and the AutoExpirer wants to keep 10240 MiB free.
>

Update: I've just been letting the local drives fill up to see what would happen when they reached my storage limit preset. Now that my first local drive is full (and the second is one recording away), myth is sending recordings to the remote drives that are the least full.

Chris Peterson's post (http://www.mythtv.org/wiki/index.php/Storage_Groups_Weighting) states that "In a tie, the drive with
the highest amount of free disk space is used first"

Based on my experiences, it should be revised as follows: "In a tie, local disks with free space will be used first (1 recording per disk), followed by remote disks with the most free space."

Jon