<br><br><div><span class="gmail_quote">On 6/7/07, <b class="gmail_sendername">Stefan van der Eijk</b> <<a href="mailto:stefan@eijk.nu">stefan@eijk.nu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 6/6/07, Michael T. Dean <<a href="mailto:mtdean@thirdcontact.com">mtdean@thirdcontact.com</a>> wrote:<br>> On 06/06/2007 11:02 AM, Brett Kosinski wrote:<br>> ><br>> > On 6/6/07, Michael T. Dean <
<a href="mailto:mtdean@thirdcontact.com">mtdean@thirdcontact.com</a>> wrote:<br>> >><br>> >> On 06/06/2007 03:19 AM, Stefan van der Eijk wrote:<br>> >>><br>> >>> I'm also seeing that my disk is filling up, but it's not due to
<br>> >>> the mysql database. I think it's due to recorded programs that<br>> >>> have been deleted, but the mythbackend process is still holding<br>> >>> onto them:<br>> >>>
<br>> >>> # lsof | grep myth | grep deleted<br>> >>> mythbacke 23174 mythtv 18r REG 8,3<br>> >>> 2894512128 28181291<br>> >>> /var/lib/mythtv/recordings/1028_20070604212500.mpg (deleted)
<br>> >>><br>> >>> Restarting the mythbackend process releases the diskspace.<br>> >><br>> >> So disable slow deletes.<br>> >><br>> >> Delete files slowly Some filesystems use a lot of resources when
<br>> >> deleting large recording files. This option makes Myth delete the<br>> >> file slowly on this backend to lessen the impact.<br>> >><br>> >> in mythtv-setup (on each backend).<br>
> >><br>> ><br>> > No, what he's describing, here, is something else. On any Unix<br>> > machine, if multiple processes have a file open, and someone comes<br>> > along and makes an unlink() call on that file, the file won't
<br>> > actually be deleted until all processes close their file handles. In<br>> > this case, mythbackend has opened the file,<br>><br>> Right.<br>><br>> > for whatever reason,<br>><br>> Perhaps because the user said to delete it and has slow deletes
<br>> enabled. Slow deletes work by opening a file, unlinking that file, and<br>> then truncating the file in small increments so as to prevent<br>> filesystems that perform poorly on deleting large files from causing
<br>> issues with recordings in progress due to I/O wait. Once the file is<br>> smaller than the truncation increment, the file is closed (and, because<br>> no other process has it open, deleted by the filesystem).
<br><br>Is it normal that this process hasn't completed 24 hrs after I deleted<br>the recording?<br><br>I still need to check if I have slow deletes enabled. I'll check and<br>do some testing over the weekend.</blockquote>
<div><br>I deleted a recording on Saturday evening, and it's still not gone yet:<br><br># lsof | grep recordings<br>mythbacke 5345 mythtv 10w REG 8,3 0 28181221 /var/lib/mythtv/recordings/nfslockfile.lock
<br>mythbacke 5345 mythtv 18r REG 8,3 3086942208 28180992 /var/lib/mythtv/recordings/1030_20070517202500.mpg (deleted)<br><br>I don't have slow deletes enabled.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> > and<br>> > has unlinked the file, but isn't closing it's currently opened file<br>> > handle,<br>><br>> So that the filesystem doesn't try to delete it all in one fell swoop<br>> that takes 5+ seconds and prevents writing a recording in progress to disk.
<br>><br>> > and so the filesystem can't actually free the underlying disk<br>> > space. If this is true, it seems like a pretty serious bug.<br>><br>> Or, if the user doesn't want this behavior, a configuration issue.
<br>><br>> I would bet that the OP thinks there may be issues with disk space<br>> usage, so upon using lsof and seeing some files open but deleted, jumped<br>> to the conclusion that this is the problem. I would guess, however,
<br>> that in fact, the OP just has slow deletes enabled and that those files<br>> will eventually be closed (and truly deleted) if the OP is patient<br>> enough to wait for them to delete rather than just shutting down
<br>> mythbackend to "prove" his theory.<br>><br>> > To the original poster, what version of mythbackend are you running?<br>> > What's your use case, here? Is there some sequence of operations
<br>> > which produces this behaviour 100% of the time?<br>><br>> The first step in proving me wrong should be to disable slow deletes<br>> (and, since that's a change in mythtv-setup, mythbackend should be shut
<br>> down at the time) and then reproduce the behavior. At that point, we'll<br>> know that any open deleted files are due to bugs.<br>><br>> Mike<br>><br>> FWIW, on my 3 backends:<br>><br>> lsof -p `pidof mythbackend` | grep -i delete
<br>><br>> gives no results. On each mythbackend has been up (running<br>> continuously--I haven't shut it down) for 9 days. I've watched and<br>> deleted many recordings (at least 10) during that time. I do have slow
<br>> deletes enabled, but all of the deletes have had time to complete.<br>><br>><br>> _______________________________________________<br>> mythtv-users mailing list<br>> <a href="mailto:mythtv-users@mythtv.org">
mythtv-users@mythtv.org</a><br>> <a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users">http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users</a><br>><br></blockquote></div><br>