[mythtv-users] Odd: Storage Group is showing two different drives as the same MythTV drive

[Mike Perkins]

Michael T. Dean wrote:
> On 07/25/2007 10:21 PM, Chris Pinkham wrote:
>> I thought that this 5-minute rate
>>   
> 
> It's a 5-second rate, right?
> 
>> was good enough, but maybe that needs tob e tightened down even more.
> 
> I think a 5-second rate is reasonable.  And, since the comparison is
> only used if the total disk space is within 16KiB, most users probably
> won't see the issue (assuming users tend to have differently-sized
> partitions because of differently-sized drives or whatever).
> 
> 
> However, if it is a 5-minute rate, I'd say it is too high (I'm sure
> checking the list of directories takes less than 5 minutes ;).  For a
> 5-minute rate, Robert's 771MB/min would mean 2 like-sized partitions
> with free space within 3855MB of each other would be treated as the same).
> 
> For the 5-second rate, on the other hand, the values seem reasonable. 
> Robert's max recording rate of 771MB/min puts the magic difference value
> at about 65MB/min (yeah, earlier I said 155--it wasn't my day for
> math).  My system (with 2 HD-3000's in each of 2 backends with only
> local storage on each) reports 277MB/min, which means filesystems have
> to be within 23MB of each other.  I doubt we'd see many systems that get
> much higher than 1GB/min--where the difference would have to be within 85MB.
> 
> But, since the time required to check all the directories is probably
> quite a bit less than 5 seconds, we might be able to lower it.  However,
> I'd think that a false positive test for uniqueness would be worse than
> a false negative.  If we think 2 directories on the same filesystem are
> actually on different filesystems, we'd be double-counting its free
> space.  If we think 2 directories on different filesystems are actually
> on the same, we'd under-estimate free space.
> 
> I guess which is worse is determined by what all else this affects
> besides the status summary.  If it affects autoexpire, would it be worse
> to fail to expire programs (and potentially run out of disk space) or to
> expire a program when doing so may not have been necessary?  IMHO,
> deleting a show that didn't have to be deleted just yet isn't too bad
> because it will likely need to be deleted for the next recording,
> anyway.  (I do realize that either of these situations would be
> /extremely/ rare due to the confluence of circumstances required to
> trigger them--i.e. users don't worry because this may happen once for
> one or two users ever in the entire future of Myth.)
> 
> Even if it does affect recording-location decision making, I don't see
> that as causing any problems.
> 
> If it only affects the summary, I guess it doesn't matter which way we
> fail.  For that case, it's just a matter of preference.
> 
> The more Robert describes what was happening (recording and/or deletion
> occuring when checking the backend status page), the more I'm amazed
> that he even saw the issue.  Probably got a fortune cookie at lunch
> yesterday that said, "Your timing will be impeccable today."
> 
Isn't the answer to this as simple as placing a small "label" type file 
on each of the volumes? If each of these either has a unique 
storage-related name or the same name e.g. "label.myth" or something, 
but uniquely generated contents, then the back end could easily 
determine whether or not the volumes were unique or not.

If the back end comes to another share and finds a label already on it, 
then it knows it's already seen it and moves on.

Mike Perkins