[mythtv-users] find_orphans.py won't delete files

[Michael T. Dean]

On 06/20/2011 06:13 AM, Bill Williamson wrote:
> On Mon, Jun 20, 2011 at 5:10 AM, Michael T. Dean wrote:
>> Pretty sure this status code was co-opted by a bunch of network file
>> systems to mean they were unable to get a lock when trying to unlink a file.
>>
>> See /usr/src/linux-`uname -r`/fs/cifs/inode.c (specifically, it seems
>> they're using it for renames pending delete, which are used to delete
>> files that are opened--similar to NFS's silly-rename trick).  That means
>> the user can probably prevent the problem by simply re-disabling the
>> (defaults to off) "Delete files slowly" setting so that his backend
>> host's CIFS (client) file system driver doesn't try to do something his
>> CIFS server can't handle.  That said, I think a better idea is to not
>> use CIFS/SMB, but...
> Thank you so much for the help with sorting this out!
> Some notes:
> -I am on CIFS (using unraid server as my file server and it's much
> easier to get working with CIFS/SMB)
> -Delete files slowly is NOT turned on, and never has been

If that's the case, it's not anything the backend is doing, so it's 
probably just some bad interaction between your CIFS server and the CIFS 
client (the Linux CIFS file system driver) or someone else actually has 
the files open.

And, now that you mention it, your original post showed the error when 
deleting a PNG preview image, so it couldn't have been MythTV's slow 
deletes, anyway.  MythTV never uses slow deletes to remove preview 
images (since they're small).

> unraid has preliminary NFS support, so I might give that a try and see
> what happens.  In the meantime, any other ideas to try?

The NFS thing might be the easiest fix--assuming that "preliminary 
support" is actually usable and safe.  :)

The downside is that NFS also has to fake a "delete on last close" 
feature, which it does using silly renames (see FAQ entry D2 at 
http://nfs.sourceforge.net/ for more on silly renames).  So, since it 
seems that something has those files open, if your NFS server doesn't 
properly handle delete-on-last-close (or uses a too-infrequent cleanup 
mechanism), you may end up with a bunch of .nfsXXXXX files on the file 
system (that could take up exactly the same space as the original 
file).  If this is the case, you may actually want to turn on slow 
deletes (which means that MythTV will open the file and start truncating 
the file slowly from the end and will finally close the file when it's < 
4MiB--meaning your .nfsXXXXX could all be < 4MiB).

Good luck.

Mike