<br><br><div><span class="gmail_quote">On 6/6/07, <b class="gmail_sendername">Michael T. Dean</b> <<a href="mailto:mtdean@thirdcontact.com">mtdean@thirdcontact.com</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 06/06/2007 03:19 AM, Stefan van der Eijk wrote:<br>> I'm also seeing that my disk is filling up, but it's not due to the<br>> mysql database. I think it's due to recorded programs that have been<br>> deleted, but the mythbackend process is still holding 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<br>Some filesystems use a lot of resources when deleting large recording<br>files. This option makes Myth delete the file slowly on this backend to
<br>lessen the impact.<br><br>in mythtv-setup (on each backend).<br></blockquote></div><br>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, and has unlinked the file, but isn't closing it's currently opened file handle, and so the filesystem can't actually free the underlying disk space. If this is true, it seems like a pretty serious bug.
<br><br>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?<br><br>Brett.<br>