Up until a few weeks ago, and since the Supermicro AOC-SAS2LP-MV8 speed issue was solved, my copy to speed was stable in the 45 MB/Sec range, and wavered very little. 

 

A couple weeks ago I upgraded by PC I usually work from to Windows 10.  I can't be certain that these issues are related to Windows 10 but the timing seems to align.

 

Symptoms:

- My copy speeds to the server have dropped from a stable 45 MB/sec (ish).  They start strong and then drop into an erratic pattern averaging 20 ish MB/sec.  The graph below doesn't do it justice, often its much more erratic.

- I can't seem to copy anything sizable off the server.  It starts strong over 100 MB/sec and then comes to a dead halt eventually timing out.

- I CAN stream video from the server without issue.

 

I have attached a screen capture from both a copy to and copy from event, along with my diagnostics download.  The configuration below in my signature is current.

 

todd-svr-diagnostics-20160514-2029.zip

Some people have found it necessary to disable SMB2 and SMB3 on Windows 10.  For directions on how to do so, see this post:

 

    http://lime-technology.com/forum/index.php?topic=47829.msg458856#msg458856

 

You are looking for the client fix near the bottom of the MS support page.

 

 

Some people have found it necessary to disable SMB2 and SMB3 on Windows 10.  For directions on how to do so, see this post:

 

    http://lime-technology.com/forum/index.php?topic=47829.msg458856#msg458856

 

You are looking for the client fix near the bottom of the MS support page.

 

thanks, that seems to have done the trick.  Much appreciated.

I've been meaning to re-open this for some time.  I thought it was solved but not soon after the copy speeds got erratic again.  (see below screen shots from a couple weeks ago).  it's actually worse than those at times.  At each dip it actually goes to near a dead stop.  Some the graph isn't long enough to actually show it dip that far but the speed drops to near zero.

 

When I disabled SMB 2 / 3, these were the instructions I followed.  This was based on the instructions for Windows 8 as there were no instructions for Windows 9.

 

To disable SMBv2 and SMBv3 on the SMB client, run the following commands:

sc.exe config lanmanworkstation depend= bowser/mrxsmb10/nsi

sc.exe config mrxsmb20 start= disabled

 

Is there any way to check and see what is enabled or disabled for SMB 1, 2, 3? 

 

Any other ideas on how to solve this copy speed issue?

That seesaw effect is usually caused by reiserfs, change your disks to xfs, if you want you can use a xfs disk on your cache slot to confirm 1st.

 

Have you upgraded '10 to Ver 1607 ??  (The "Anniversary Edition" that was just released 2 weeks ago)

 

I don't recall having any issues even before that; but I definitely don't have any speed issues now.  Just confirm that copies FROM my servers are consistently 110+ MB/s  [Copied a couple of 15-20GB image files from both a v6 server with XFS drives and a v5 server with RFS]

 

Writes have been the normal 35-45MB speed I've always seen.

 

This seesaw effect only happens on v6 with reiserfs and copys to server, reads from server and writes to reiserfs v5 server are normal.

In which case my tests with RFS aren't relevant, as the only remaining Reiser disks I have are on my one remaining v5 server [Haven't upgraded that one for a variety of reasons ... primarily (a) it's by far my slowest processor (Atom D525) and the added CPU demands for v6 would likely be a bit more than I want to hit it with;  and (b)  it works perfectly (i.e. "if it ain't broke, don't fix it) ]

 

So if all the copy speed issues TODDLT is having are indeed with Reiser formatted disks, that's likely the problem ... i.e. it's not a Windows 10 issue.

 

So if all the copy speed issues TODDLT is having are indeed with Reiser formatted disks, that's likely the problem ... i.e. it's not a Windows 10 issue.

 

Yeah, symptoms look very similar to this case, of course I can be wrong and it can be a different problem, but reiserfs would be my first guess.

Read through the other thread you linked to => Agree, it certainly sounds like that's the issue here as well.

 

TODDLT => Are the disks involved indeed Reiser ??

 

Read through the other thread you linked to => Agree, it certainly sounds like that's the issue here as well.

 

TODDLT => Are the disks involved indeed Reiser ??

 

They indeed all are.  They predate my upgrade to v6 (except 1 i think). 

How do we determine if this is the issue? 

Can they be converted?

 

I've been meaning to ask what the real difference i between Reiser and XFS, what the reasons are for changing the system and why I would want to have two different file systems in the same server even if it is "OK" why have two?   

So this is as good a time as any if anyone can answer that.

You can't just convert the file system "in place", but you can move all of the data off a disk;  reformat it as XFS; and then copy all the data back to it.  There are some caveats you have to follow to be sure you don't lose all your data in the process -- the key is to absolutely avoid the "user share copy bug".

 

The SAFEST way (but not the quickest) is to, one-drive-at-a-time, copy the entire contents to another drive [either on the server or on another PC in your network];  verify that they are good copies (depending on what you use to copy the data this may be done as part of the copying process); then reformat the disk to XFS (a VERY quick and easy process -- just stop the array, choose XFS for that disk; and restart the array ... it will format the disk is a couple minutes);  and finally copy all the data back to it.

 

You might want to do that with one disk; and then confirm by copying to/from that disk that your speed issue has been fully resolved.    If so, then you can patiently do another disk every day or so until they're all converted.

 

You can't just convert the file system "in place", but you can move all of the data off a disk;  reformat it as XFS; and then copy all the data back to it.  There are some caveats you have to follow to be sure you don't lose all your data in the process -- the key is to absolutely avoid the "user share copy bug".

 

The SAFEST way (but not the quickest) is to, one-drive-at-a-time, copy the entire contents to another drive [either on the server or on another PC in your network];  verify that they are good copies (depending on what you use to copy the data this may be done as part of the copying process); then reformat the disk to XFS (a VERY quick and easy process -- just stop the array, choose XFS for that disk; and restart the array ... it will format the disk is a couple minutes);  and finally copy all the data back to it.

 

You might want to do that with one disk; and then confirm by copying to/from that disk that your speed issue has been fully resolved.    If so, then you can patiently do another disk every day or so until they're all converted.

 

1. Will this definitively solve the problem? 

 

2. Is there likely to be another fix that won't require this?  Anything else, it will be quite an undertaking.

 

3. Does v6 just not play well with Reisers? Is that why the change?

 

4. What if i did a drive replacement, one drive at a time using XFS as the format for each new drive?  this may work for all but the SSD's, because i'm not replacing them.  The others i can rotate a single drive through.

 

thanks all for the help.

3. Does v6 just not play well with Reisers? Is that why the change?

Not clear.  It could be something to do with the switch to 64-bit drivers in v6.  Since ReiserFS is no longer being actively maintained (the original developer is in jail for murdering his wife), then if it is a driver issue it may never be fixed.    ReiserFS is now considered to be in its end-of-life phase as far as Linux is concerned.  A shame as it probably has the best tools for recovering from file system level corruption.

 

4. What if i did a drive replacement, one drive at a time using XFS as the format for each new drive?  this may work for all but the SSD's, because i'm not replacing them.  The others i can rotate a single drive through.

if by drive replacement you mean the normal unRAID procedure for replacing a failed drive then this will not work.    You cannot change the format at this point - the rebuild always puts back the original format.  As was mentioned the only way to switch file system types is by copying the data (there is forum sticky covering this).

It's not an absolute that this will resolve it => HOWEVER, Johnnie has done some pretty extensive testing and saw a very similar issue which indeed was due to the Reiser disks under v6.    As he noted when I mentioned I had no issues with the speeds with Reiser, my remaining RFS disks are all on v5.

 

I would do as I suggested above => convert ONE drive to XFS using the process I outlined; then see if reads/writes to/from THAT specific disk still have speed variances.    If so, then that probably isn't the issue.  If not, then indeed that's what's happening; and you can -- at your leisure -- convert the remaining drives to XFS.

 

It's really not a difficult process => the only "hassle" is you need to have enough free space to copy an entire drive's contents to it.    While it DOES take a long time to do the very cautious steps I outlined (basically about 1-2 days/drive); it only takes perhaps 10 minutes if "YOUR" time ... all the rest is just "Computer Time".  i.e. you start the copy;  a few hours later you start the validation (unless you used a copy utility that has validation built in);  then a few hours later you spend 5 minutes stopping the array; changing the format type for the drive you just copied; then starting the array and letting it format that drive; and then you start the copy of all the data back to the newly formatted drive (ideally this should also be with verification).

 

 

It's not an absolute that this will resolve it => HOWEVER, Johnnie has done some pretty extensive testing and saw a very similar issue which indeed was due to the Reiser disks under v6.    As he noted when I mentioned I had no issues with the speeds with Reiser, my remaining RFS disks are all on v5.

 

I would do as I suggested above => convert ONE drive to XFS using the process I outlined; then see if reads/writes to/from THAT specific disk still have speed variances.    If so, then that probably isn't the issue.  If not, then indeed that's what's happening; and you can -- at your leisure -- convert the remaining drives to XFS.

 

It's really not a difficult process => the only "hassle" is you need to have enough free space to copy an entire drive's contents to it.    While it DOES take a long time to do the very cautious steps I outlined (basically about 1-2 days/drive); it only takes perhaps 10 minutes if "YOUR" time ... all the rest is just "Computer Time".  i.e. you start the copy;  a few hours later you start the validation (unless you used a copy utility that has validation built in);  then a few hours later you spend 5 minutes stopping the array; changing the format type for the drive you just copied; then starting the array and letting it format that drive; and then you start the copy of all the data back to the newly formatted drive (ideally this should also be with verification).

 

OK thanks for the help.  I'll test one drive, possibly this weekend and go from there.

 

It's not an absolute that this will resolve it => HOWEVER, Johnnie has done some pretty extensive testing and saw a very similar issue which indeed was due to the Reiser disks under v6.    As he noted when I mentioned I had no issues with the speeds with Reiser, my remaining RFS disks are all on v5.

 

I would do as I suggested above => convert ONE drive to XFS using the process I outlined; then see if reads/writes to/from THAT specific disk still have speed variances.    If so, then that probably isn't the issue.  If not, then indeed that's what's happening; and you can -- at your leisure -- convert the remaining drives to XFS.

 

It's really not a difficult process => the only "hassle" is you need to have enough free space to copy an entire drive's contents to it.    While it DOES take a long time to do the very cautious steps I outlined (basically about 1-2 days/drive); it only takes perhaps 10 minutes if "YOUR" time ... all the rest is just "Computer Time".  i.e. you start the copy;  a few hours later you start the validation (unless you used a copy utility that has validation built in);  then a few hours later you spend 5 minutes stopping the array; changing the format type for the drive you just copied; then starting the array and letting it format that drive; and then you start the copy of all the data back to the newly formatted drive (ideally this should also be with verification).

 

OK thanks for the help.  I'll test one drive, possibly this weekend and go from there.

 

FWIW, I had a similar issue (in Win 7) with writes timing out and changing the format of my disks to XFS from Reiser did the trick.

Can someone recommend a good copy tool with verification?  I've not really worried much with this before but copying near 2 TB, I thik it's worthwhile.  A freebie would be nice but certainly willing to pay for a useful tool if its not out of hand.  I looked at XXcopy but $100 felt like a bit much for a copy tool. 

 

Any help is appreciated.

http://lime-technology.com/forum/index.php?topic=37490.msg449941#msg449941

Glad I came across this topic, I have 4 disks which are still ReiserFS from my old V5 config and when I upgraded to v6 I just didnt have enough space to manually copy 1 disk at a time. I got a spare 3TB drive im going to pop in my PC and copy disk at time and slowly convert all my disks to XFS.

Can someone recommend a good copy tool with verification?  I've not really worried much with this before but copying near 2 TB, I thik it's worthwhile.  A freebie would be nice but certainly willing to pay for a useful tool if its not out of hand.  I looked at XXcopy but $100 felt like a bit much for a copy tool. 

 

Any help is appreciated.

 

For Windows, the free edition of Teracopy should fulfil your requirements.

 

OK so this seems odd.  I found an old 2 TB drive that I havne't used in about a year.  put it in an external enclosure connected eSata and after formatting ran chkdsk /r just to make sure there were no bad sectors.  It was previously running in my unRaid rig and was really just wanting some verification since it sat on a shelf. 

 

See the attached results.  the summary says there were 9 files in 15 indexes on a freshly formatted drive, directory shows nothing.  Is that part of the NTFS format structure?

 

 

Here is another question.  I'm pretty sure there is a way to mount a drive outside of the array in unRaid.  Wouid it be better to do that and copy the files over, or do what I'm working on now which is a drive connected to my Win10 machine?

Can someone recommend a good copy tool with verification?  I've not really worried much with this before but copying near 2 TB, I thik it's worthwhile.  A freebie would be nice but certainly willing to pay for a useful tool if its not out of hand.  I looked at XXcopy but $100 felt like a bit much for a copy tool. 

 

Any help is appreciated.

 

For Windows, the free edition of Teracopy should fulfil your requirements.

 

Thanks, i'll be on that tonight.

OK so this seems odd.  I found an old 2 TB drive that I havne't used in about a year.  put it in an external enclosure connected eSata and after formatting ran chkdsk /r just to make sure there were no bad sectors.  It was previously running in my unRaid rig and was really just wanting some verification since it sat on a shelf. 

 

See the attached results.  the summary says there were 9 files in 15 indexes on a freshly formatted drive, directory shows nothing.  Is that part of the NTFS format structure?

 

Wild guess at this point would be that these files are hidden system files.  Have you googled about this issue?  And why do you care as you formatted the drive and you knew this would cobber everything on the drive?

OK so this seems odd.  I found an old 2 TB drive that I havne't used in about a year.  put it in an external enclosure connected eSata and after formatting ran chkdsk /r just to make sure there were no bad sectors.  It was previously running in my unRaid rig and was really just wanting some verification since it sat on a shelf. 

 

See the attached results.  the summary says there were 9 files in 15 indexes on a freshly formatted drive, directory shows nothing.  Is that part of the NTFS format structure?

 

Wild guess at this point would be that these files are hidden system files.  Have you googled about this issue?  And why do you care as you formatted the drive and you knew this would cobber everything on the drive?

 

They are, don't worry about them. https://support.microsoft.com/en-us/kb/103657