Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Dev

Re: [mythtv-commits] Ticket #4179: (patch included) BackendQueryDiskSpace incorrectly aggregates identical local disks

 

 

MythTV dev RSS feed   Index | Next | Previous | View Threaded


mtdean at thirdcontact

Nov 16, 2007, 4:52 PM

Post #1 of 6 (822 views)
Permalink
Re: [mythtv-commits] Ticket #4179: (patch included) BackendQueryDiskSpace incorrectly aggregates identical local disks

On 11/16/2007 07:45 PM, MythTV wrote:
> #4179: (patch included) BackendQueryDiskSpace incorrectly aggregates identical
> local disks
>
>
> Comment(by Chris Moates):
>
> I failed to take into account two directories on the same disk, for
> different storage groups. As a result, this patch will fix one bug but
> introduce another. Please reject this patch.

But, on the bright side, once you start recording some shows, your disks
will again show up as different. It's only really affecting you now
because the disks are new and empty.

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


six at mox

Nov 16, 2007, 7:17 PM

Post #2 of 6 (744 views)
Permalink
Re: [mythtv-commits] Ticket #4179: (patch included) BackendQueryDiskSpace incorrectly aggregates identical local disks [In reply to]

Michael T. Dean wrote:
> But, on the bright side, once you start recording some shows, your disks
> will again show up as different. It's only really affecting you now
> because the disks are new and empty.
While true, any time the (identical) disks have nearly the same amount of free space, the problem would resurface, however intermittently that might be. I considered wasting some space outside of the partition on each disk to give them different sizes (500k would do it) but that feels really hacky. :) I'm experimenting with another solution, and if I make good progress, I'll report as such.


It's only an edge case; a minor issue at best.

Chris
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mtdean at thirdcontact

Nov 17, 2007, 8:55 AM

Post #3 of 6 (733 views)
Permalink
Re: [mythtv-commits] Ticket #4179: (patch included) BackendQueryDiskSpace incorrectly aggregates identical local disks [In reply to]

On 11/16/2007 10:17 PM, Chris Moates wrote:
> Michael T. Dean wrote:
>
>> But, on the bright side, once you start recording some shows, your disks
>> will again show up as different. It's only really affecting you now
>> because the disks are new and empty.
>>
> While true, any time the (identical) disks have nearly the same amount of free space, the problem would resurface, however intermittently that might be. I considered wasting some space outside of the partition on each disk to give them different sizes (500k would do it) but that feels really hacky. :) I'm experimenting with another solution, and if I make good progress, I'll report as such.
>
>
> It's only an edge case; a minor issue at best.
See the thread at
http://www.gossamer-threads.com/lists/mythtv/users/280805#280805 . Note
that Chris Pinkham (one of the responders in that thread) is the author
of the code that identifies the "unique" disks (and the rest of the
Storage Groups code, too), so his posts are a bit more than armchair
quarterbacking.

There, we agreed that a false positive test for uniqueness is /far/
better than a false negative test.

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


six at mox

Nov 17, 2007, 10:35 AM

Post #4 of 6 (732 views)
Permalink
Re: [mythtv-commits] Ticket #4179: (patch included) BackendQueryDiskSpace incorrectly aggregates identical local disks [In reply to]

Michael T. Dean wrote:
> On 11/16/2007 10:17 PM, Chris Moates wrote:
>
>> Michael T. Dean wrote:
>>
>>
>>> But, on the bright side, once you start recording some shows, your disks
>>> will again show up as different. It's only really affecting you now
>>> because the disks are new and empty.
>>>
>>>
>> While true, any time the (identical) disks have nearly the same amount of free space, the problem would resurface, however intermittently that might be. I considered wasting some space outside of the partition on each disk to give them different sizes (500k would do it) but that feels really hacky. :) I'm experimenting with another solution, and if I make good progress, I'll report as such.
>>
>>
>> It's only an edge case; a minor issue at best.
>>
> See the thread at
> http://www.gossamer-threads.com/lists/mythtv/users/280805#280805 . Note
> that Chris Pinkham (one of the responders in that thread) is the author
> of the code that identifies the "unique" disks (and the rest of the
> Storage Groups code, too), so his posts are a bit more than armchair
> quarterbacking.
>
> There, we agreed that a false positive test for uniqueness is /far/
> better than a false negative test.
Thanks for the link to the other thread.

I am finishing up a patch that will still prefer false positives, but
reduce the false rate a bit. Short version, if the disks are both local,
and have the same st_dev from stat(), then they are the same device, and
can be merged. If the st_dev numbers are different, then the devices are
unique, and should not be merged. If stat() fails, then we fall back to
the way it was before my patch, using only disk capacity and free space.
The st_dev method is the same way df works, so it seems likely to be
reliable.

Chris
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mtdean at thirdcontact

Nov 17, 2007, 11:59 AM

Post #5 of 6 (737 views)
Permalink
Re: [mythtv-commits] Ticket #4179: (patch included) BackendQueryDiskSpace incorrectly aggregates identical local disks [In reply to]

On 11/17/2007 01:35 PM, Chris Moates wrote:
> I am finishing up a patch that will still prefer false positives, but
> reduce the false rate a bit. Short version, if the disks are both local,
> and have the same st_dev from stat(), then they are the same device, and
> can be merged. If the st_dev numbers are different, then the devices are
> unique, and should not be merged. If stat() fails, then we fall back to
> the way it was before my patch, using only disk capacity and free space.
> The st_dev method is the same way df works, so it seems likely to be
> reliable.

Yeah. I finally got around to catching up on the IRC scrollback (I
always do mail first, then IRC) and saw your conversation with Chris.
Sounds (and your patch looks) like a good approach.

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


kormoc at gmail

Nov 17, 2007, 3:15 PM

Post #6 of 6 (735 views)
Permalink
Re: [mythtv-commits] Ticket #4179: (patch included) BackendQueryDiskSpace incorrectly aggregates identical local disks [In reply to]

On Nov 17, 2007 8:55 AM, Michael T. Dean <mtdean [at] thirdcontact> wrote:
> See the thread at
> http://www.gossamer-threads.com/lists/mythtv/users/280805#280805 . Note
> that Chris Pinkham (one of the responders in that thread) is the author
> of the code that identifies the "unique" disks (and the rest of the
> Storage Groups code, too), so his posts are a bit more than armchair
> quarterbacking.
>
> There, we agreed that a false positive test for uniqueness is /far/
> better than a false negative test.
>
> Mike

Well, I'm gonna interject some armchair quarterbacking.

Thoughts on just having a simple file in the root dir of each storage
dir that uniquely identifies it? I'd suggest .storage_group_uuid or
similar, that way it's 'invisible' but easily findable.

Just a thought.

~Rob Smith
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

MythTV dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.