[mythtv-users] Mythtv filling up disk space?

Michael T. Dean mtdean at thirdcontact.com
Wed Jun 6 18:04:19 UTC 2007

On 06/06/2007 11:02 AM, Brett Kosinski wrote:
> On 6/6/07, Michael T. Dean <mtdean at thirdcontact.com> wrote:
>> On 06/06/2007 03:19 AM, Stefan van der Eijk wrote:
>>> I'm also seeing that my disk is filling up, but it's not due to
>>> the mysql database. I think it's due to recorded programs that
>>> have been deleted, but the mythbackend process is still holding
>>> onto them:
>>> # lsof | grep myth | grep deleted
>>> mythbacke 23174     mythtv 18r      REG                8,3
>>> 2894512128   28181291
>>> /var/lib/mythtv/recordings/1028_20070604212500.mpg (deleted)
>>> Restarting the mythbackend process releases the diskspace.
>> So disable slow deletes.
>> Delete files slowly Some filesystems use a lot of resources when
>> deleting large recording files.  This option makes Myth delete the
>> file slowly on this backend to lessen the impact.
>> in mythtv-setup (on each backend).
> No, what he's describing, here, is something else.  On any Unix
> machine, if multiple processes have a file open, and someone comes
> along and makes an unlink() call on that file, the file won't
> actually be deleted until all processes close their file handles.  In
> this case, mythbackend has opened the file,


> for whatever reason,

Perhaps because the user said to delete it and has slow deletes
enabled.  Slow deletes work by opening a file, unlinking that file, and
then truncating the file in small increments so as to prevent
filesystems that perform poorly on deleting large files from causing
issues with recordings in progress due to I/O wait.  Once the file is
smaller than the truncation increment, the file is closed (and, because
no other process has it open, deleted by the filesystem).

> and
> has unlinked the file, but isn't closing it's currently opened file
> handle,

So that the filesystem doesn't try to delete it all in one fell swoop
that takes 5+ seconds and prevents writing a recording in progress to disk.

> and so the filesystem can't actually free the underlying disk
> space.  If this is true, it seems like a pretty serious bug.

Or, if the user doesn't want this behavior, a configuration issue.

I would bet that the OP thinks there may be issues with disk space
usage, so upon using lsof and seeing some files open but deleted, jumped
to the conclusion that this is the problem.  I would guess, however,
that in fact, the OP just has slow deletes enabled and that those files
will eventually be closed (and truly deleted) if the OP is patient
enough to wait for them to delete rather than just shutting down
mythbackend to "prove" his theory.

> To the original poster, what version of mythbackend are you running?
> What's your use case, here?  Is there some sequence of operations
> which produces this behaviour 100% of the time?

The first step in proving me wrong should be to disable slow deletes
(and, since that's a change in mythtv-setup, mythbackend should be shut
down at the time) and then reproduce the behavior.  At that point, we'll
know that any open deleted files are due to bugs.


FWIW, on my 3 backends:

lsof -p `pidof mythbackend` | grep -i delete

gives no results.  On each mythbackend has been up (running
continuously--I haven't shut it down) for 9 days.  I've watched and
deleted many recordings (at least 10) during that time.  I do have slow
deletes enabled, but all of the deletes have had time to complete.

More information about the mythtv-users mailing list