[mythtv-users] MythTV 0.23 backend suddenly auto-expired a ton of recordings...

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Fri Aug 13 06:43:34 UTC 2010


    > Date: Fri, 13 Aug 2010 02:12:42 -0400
    > From: "Michael T. Dean" <mtdean at thirdcontact.com>

    > If MythTV tried to record to that directory, it would potentially fill 
    > up the root file system because it would have nothing to autoexpire (as, 
    > chances are all the real recording directories are on other file systems 
    > on other partitions or drives and not directories on the root file 
    > system).

Is this the case even if storage groups are not in use?  Or in Myths
too old to know about storage groups?  Or does Myth always check in
whatever FS it thinks it's expiring in for the actual file to before
it tries to expire it?  (I'm thinking now of the failure mode where it
winds up deleting things from the recorded table but doesn't actually
delete any recording files, because it can't get at them 'cause they
aren't mounted---in that case, the bits are still on disk [once
remounted], but Myth doesn't know that and would have to have the
orphans refound, etc.)

I guess maybe the other failure mode might come from a situation where
Myth is truly deleting files from the right place, but the amount of
freespace fails to increase, hence causing it to continue deleting.
I -think- we may have heard of such an event, but it's pathological,
since it implies that Myth is asking for the freespace of the wrong
filesystem.  I can't remember if there was a bug that tickled that;
I recall early SG behavior where the slop was too big and several
brand-new, empty, identically-sized filesystems tended to confuse
SG about what was where.  But I can't imagine that could persist
long enough to cause expiration mishaps, since it's extremely unlikely
that the same-freespace behavior would persist past a recording or
two.

Actually, come to think of it, I -have- seen that pathological
behavior, at least briefly, on some JFS's.  I recall a few situations
where file deletion didn't appear to modify the freespace, even though
the file was absolutely not being held open by some other process.
It sometimes took writing something to the filesystem to reset the
freespace.  But now I can't recall if there might have been NFS in
the mix; having long caching there might lead to misleading results,
although IIRC the caches were no longer than 60 seconds and I
sometimes saw the behavior for many minutes.  (But I haven't seen
it in a long time, and certainly not for the OP's seven hours... :)


More information about the mythtv-users mailing list