[mythtv-users] rebalance deleted recordings

[Brian J. Murrell]

On Thu, 2014-03-20 at 13:44 +0000, Simon Hobson wrote: 
> 
> Ah, IMO that is you problem.

Not really.  The same problem happens even if you expire recordings
right away.  But let's discuss that below.  First I will respond to your
other comments...

> If a recording is deleted, why keep it around ?

I would ask instead, why expire it before you need the space?  What
benefit do you get from expiring it before you need the space.  I will
counter with the benefit of delaying expiration until space is needed is
that it extends the window in which you can pull a deleted recording
back.

> Keep it for a few days (allows for reversal of accidental deletions),

But why not extend that window as much as possible?  That gives you
longer to notice it's gone or decide that you want it back, etc.

> but if you deleted it then presumably you no longer want it
>  - if you think you might want it then mark it as watched and don't delete it.

One could take that approach, but really, it's quite orthogonal to the
problem at hand.

> It's like people I've come across that never empty the Wastebasket (aka Trash or Recycle Bin) - because they are actually using it as a storage folder !

I disagree.  They have progressed their thinking beyond the simplistic,
naive concept that a lot of "empty" disk space is a good thing.  It's
not really.  A lot of "available" disk space is a good thing, yes.  But
if that "available" disk space is otherwise being used as a purge cache,
that provides the benefits I outlined above.  It's disk space that is
available if needed but otherwise provides a cache of items that could
be brought back from deletion.

> However, there is part of your issue which is correct - if a drive is almost full and has no deleted recordings on it then you'll have the problem.

Right.  This is where the opening comment picks up.  Deleting things
right away is just a deferral of this same problem.  Ultimately you need
to rebalance because you have a disk of recordings that you are not
ready to delete/expire yet and you have disks that have free/available
(where available means it might be full, but with some expirable -- i.e.
deleted recordings on it) space and you want to balance that
available/free space.

The only real difference is that with the "expire-when-you-need-to"
method, you need to consult the Myth database to determine where
"available" (i.e. vs. "free" which can be determined with a simple "df")
space is.


> I aim to keep more free space than the minimum I've told Myth to keep

But why?  All you are achieving by doing that is reducing your
deleted-recording recovery window.  I can't see how that is useful given
that Myth will manage "available" space.

>  - and I only rebalance if one drive is getting quite close.

Again, that's just a different flavour of the same problem.

> I find it hard to believe that if you weren't keeping a load of deleted recordings around, that the recordings wouldn't balance themselves better over time - meaning you'd need to manually rebalance once after clearing some of the old deleted recordings.

Well, you better start believing it.  Whether I keep deleted recordings
around and let Myth expire them as it needs space for new recordings has
absolutely no bearing on this problem.  A full (where full means a disk
with no deleted-but-unexpired recordings) happens no matter when you
expire recordings and Myth understands "available" space and treats it
like "free" space.

But ultimately, if Myth needs to balance spindle I/O it is going to use
"full" disks and expire recordings on them even if they were not marked
for deletion (and not marked keep-forever of course), regardless of when
you expire deleted recordings.

TL;DR: To Myth, available space == free space and prematurely creating
free space is just a warm fuzzy feeling that you, as a human needs.

Cheers,
b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20140320/d8b7ddf2/attachment.sig>