[mythtv-users] Mythtv filling up disk space?

Stefan van der Eijk stefan at eijk.nu
Mon Jun 18 07:23:27 UTC 2007


On 6/7/07, Stefan van der Eijk <stefan at eijk.nu> wrote:
>
> 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.


I deleted a recording on Saturday evening, and it's still not gone yet:

# lsof | grep recordings
mythbacke  5345     mythtv   10w      REG                8,3          0
28181221 /var/lib/mythtv/recordings/nfslockfile.lock
mythbacke  5345     mythtv   18r      REG                8,3 3086942208
28180992 /var/lib/mythtv/recordings/1030_20070517202500.mpg (deleted)

I don't have slow deletes enabled.


> > > 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20070618/0e072ec7/attachment.htm 


More information about the mythtv-users mailing list