[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,
> > 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
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.
> 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
More information about the mythtv-users