[mythtv-users] Mythtv filling up disk space?

Stefan van der Eijk stefan at eijk.nu
Thu Jun 7 21:52:05 UTC 2007


On 6/6/07, Michael T. Dean <mtdean at thirdcontact.com> wrote:
> 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,
>
> Right.
>
> > 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).

Is it normal that this process hasn't completed 24 hrs after I deleted
the recording?

I still need to check if I have slow deletes enabled. I'll check and
do some testing over the weekend.

> > 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.
>
> Mike
>
> 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.
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>


More information about the mythtv-users mailing list