Weird SMB/Oplock problem

[Pancakes]

For a while now I have had issues where files will not duplicate properly after downloading and moving them, It doesn't happen all the time, and I have been busy so I never bothered looking into it

 

Today I noticed that a TV show would not duplicate

 

 

So I checked to see if anything had it open, and it didn't. HOWEVER my "deluge" account which is used by Deluge running on a CentOS 7 VM had the original download file open, which no longer existed. I thought this was weird, because how can you have a file open which doesn't exist?

 

 

So I closed the file, and then the file in /Data/Media/TV Shows/wherver duplicated fine

 

Is this a DrivePool issue, or a Windows SMB issue, or a CentOS/Deluge issue?

 

Related to this, sometimes I have a problem where I will download a file, move it and find that the file is now also back in the downloads folder, because Deluge is still hanging onto it. Closing the session/open file makes the file disappear 

 

When I add a torrent, the file will start downloading to \\FS01\Data\Downloads\Incomplete, and when done it will move to \\FS01\Data\Downloads. From there I will remove the torrent from Deluge, and move it to \\FS01\Data\Media\ and then a subfolder

 

All of these folder are on the same pool. \\FS01\Data\Downloads is NOT duplicated, the rest of pool is 

 

Does anyone have any suggestions on how I should resolve this?

[Christopher (Drashna)]

To make sure, CentOS is running Deluge, which moves completed files to a CIFS/SMB share? 

 

And when it does that, that's where it has the issue? 

If so, then yeah, oplocks can (do) prevent the service from running background tasks like the listed ones, as the files are "locked". 

 

 

But if deluge isn't using the files anymore... then it sounds like CentOS is not release the locks properly. 

.

 

 

That said, could you make sure you're on the latest version of StableBit Drivepool?  There are a few fixes involving oplocks, and the like.  These may fix the issues you're seeing. 

http://dl.covecube.com/DrivePoolWindows/beta/download/StableBit.DrivePool_2.2.0.765_x64_BETA.exe

[Pancakes]

Thanks for the suggestions, you were kind of correct

 

On the CentOS VM, I have \\FS01\Data\Downloads\ mapped via SMB/CIFS

 

Torrents download directly to \\FS01\Data\Downloads\Incomplete, and then when they are done, they are moved to \\FS01\Data\Downloads. So the files reside on the pool all the time

 

Once they are there, I rename them and move them. But I guess CentOS is still holding onto the original file, even though i successfully renamed and moved the file. I even gave the Deluge account explicit DENY NTFS permissions on the media share, so its weird how its still holding onto the file that it thinks is still in downloads

 

Ill install the latest and see how it goes, I am on 734 so I am a few behind. I may look into downloading to a different volume all together, that might make more sense 

[Christopher (Drashna)]

Well, worst case, you *could* probably script something that restarts the SMB/CIFS client on CentOS once the download completes and moves the file.  I believe that Deluge does support that.   

 

 

The problem is that if you're currently using it, it *could* corrupt things.  So in this case, it may be better to download locally and then move over to the destination share.  

 

 

 

Personally, I have the download clients run on the storage server, but I have a dedicated "temp storage" disk in the system which torrents and other stuff download to, and as a staging area.  Other software then moves the files from this disk to the storage pool.   It avoids locking issues, permissions issues, and other "weird" issues. 

[Pancakes]

Honestly I am not all that happy with Deluge anyway, and all my other systems are Debian based so its kind of annoying I set it up on CentOS all those years ago

 

Tomorrow I will install the latest DrivePool version and see what happens, if its still acting funny then I will just rebuild my torrenting setup

[Christopher (Drashna)]

Ah, well, I can understand that.  

 

If you wipe it, maybe debian will handle things better. 

 

Either way, if you still have issues, let me know.

[Pancakes]

So far so good, Ill wait a little while longer before calling it completely solved on my end, but I think its fixed

[Christopher (Drashna)]

I'm glad to hear it!

 

If it does come back, please do let us know!

[Pancakes]

Sadly it looks like this is still a problem. I still don't really know if its a Deluge or a Drivepool problem. I can't find a single thread anywhere about Deluge doing the same thing for anyone else

 

I am going to try and change some things in Deluge and see if it fixes the problem 

[Christopher (Drashna)]

Well, the problem is "all of the above".

 

The Oplock issue is one with DrivePool, but it's being caused by the others. And I'm not entirely sure about why.

 

If you want, grab tracing logs, and I'll flag this for the developer.

http://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection

 

http://wiki.covecube.com/StableBit_Troubleshooter

[Pancakes]

How long are the logs stored? I don't want to submit them now and have you guys go through tons of logs only to find it hasn't done it in the time the logs were there 

[Christopher (Drashna)]

For the tracing logs?  It goes though it pretty fast.

 

Basically, if you can stop the logging as SOON as the issue manifests, awesome.  If not, the sooner you can, the better.

Specifically, the logs are 10MB in length, but with the file system stuff, that's .... a lot of data that can be generated in a short period of time.  We limit it, so that you don't have 100's of GB of logs on the system drive.  But that means that the window is narrower.

 

And because of this, there isn't really a window I can list. It entirely depends on what is accessing the pool.  The more there is, the more gets pruned.

 

 

(also, the larger the log is, the harder it is for us to go though and find a specific issue, as well, so shorter is better for "human eyes")