This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
I currently store a few TrueCrypt containers on my ReadyNAS 316. I use TryCrypt to mount these containers when i wish to copy/paste additional files into the container. This has always worked fine. Once i've mounted the container in Windows, i can navigate/copy/use files within the container as usual (windows mounts the container as a new drive in Windows).
However, overthe last few days, copying any new file to the container stored on the NAS suddenly dropped to extremely slow speeds. Every time i copy a file to the mounted container, the speed drops after about 3 seconds, to fluctuate between 0KB/s and approx 700KB/s. This happens whenever i copy a file from Windows to the container on the NAS, and also when i copy/paste files already stored in the TrueCrypt container. This makes copying large GB files to the container near impossible. Copying files to NAS works fine, its only when copying to/within a TrueCrypt container.
Does anyone have any ideas why this may be happening all of a sudden?
I have a new local build of the SMB Plus app that adds an option for this setting. Get it from here, and install from the Apps tab, using the Upload button. Then launch the SMB Plus app, go to the Write Options tab, and disable Strict Sync.
We plan to make this a per-share option in a future firmware release.
Are you are using dynamic containers, or static ones, and is CoW (Copy on Write, aka BitRot Protection) enabled for the share? I only use static containers and have not run into this, but I can see how it could become a problem on a CoW system to expand a very large file like a dynamic TrueCrypt container. Using static containers reserves all the required space up front, which makes it contiguous and precludes the need for future expansion. But some users do not want to reserve a lot of otherwise unused space. I do, because I use different containers for backing up different PC's and since OS6 still does not have share level quotas (that OS4.x did 10 years ago!!), it's the only way I can use "disk space" as the key to trimming old backups where each machine has it's own specified space available.
If you want to use dynamic containers, you definately want to have CoW disabled on the share.
BTW, TrueCrypt is a bit old in the tooth; you should probably look at VeraCrypt.
I use only static containers. In fact i've used the same containers for a long time. Only recently did i start having this issue. I checked CoW also, and the share definitely has is enabled.
I also tried VeryCrypt as suggested. Did a fresh install and created a static 3GB container on the NAS. The same issue occurs. Copy speed starts of about 40 MB/s and immediately begins to drop to below 1MB/s. Extremely frustrating.
I'm running firmware 6.9.0, which i do believe i updated not to long ago. Is there a chance that the change from the previous version could be the cause of my issue?
I have no idea what NIC bonding is. However, i can tell you that to my knowledge i havent changed anything since before i started having this issue.
I have snapshots enabled on all my shares. Snapshot Management is set to "Smart" and the Snapthot Schedule is set to "Daily". Additionall, the "Allow Snapshot Access" checkbox is not ticked.
I have snapshots enabled on all my shares. Snapshot Management is set to "Smart" and the Snapthot Schedule is set to "Daily". Additionall, the "Allow Snapshot Access" checkbox is not ticked.
Snapshots should be turned off on any shares that hold your TrueCrypt or Veracrypt containers. Otherwise, the container files will become very fragmented over time, and that will hurt their performance.
After you turn off the snapshots in these shares, you should manually delete all the existing snapshots in them. After that, run a balance and then a defrag (using the maintenance functions on the volume settings wheel).
I'm running firmware 6.9.0, which i do believe i updated not to long ago. Is there a chance that the change from the previous version could be the cause of my issue?
There were some network issues in the 6.9.0 x86 ethernet drivers which should have been fixed automatically (Netgear pushed a hot-fix). If your NAS can reach the internet, then the hot fix should have been picked up by now.
You can confirm this by downloading the NAS log zip bundle, and looking at apt-history.log. Towards the bottom you should see something like
Snapshots should be turned off on any shares that hold your TrueCrypt or Veracrypt containers. Otherwise, the container files will become very fragmented over time, and that will hurt their performance.
After you turn off the snapshots in these shares, you should manually delete all the existing snapshots in them. After that, run a balance and then a defrag (using the maintenance functions on the volume settings wheel).
I never considered that snapshots would fragment them even with static containers and CoW disabled. Mine don't seem to have any issue, though I am on a 516. And I do have an EDA500 dedicated to them.
I only have the one ethernet cable attached, so no NIC bonding i guess.
I did have snapshots turned on. However i've just created a new share on the NAS and disabled snapshots. I also created a new 3GB TrueCrypt container in this share. The problem of slow copy speed still occurs in this new container. For the first 1-2 seconds the filecopies as regular speeds, before dropping off to about 300-700 KB/s.
I also checked the hotfix, using the log file. It has similar text to what you pasted below, indicating that i have the 6.9.0+4 hotfix.
I would say that i don't see any speed drops for NAS shares with similar size files.
For example, i can create a duplicate 1GB file inside a share by copy/pasting (location of both files is the same. The speed is fine in this case. If i do the same thing to a similar size file already saved in the container the speed drops.
For example, i can create a duplicate 1GB file inside a share by copy/pasting (location of both files is the same. The speed is fine in this case. If i do the same thing to a similar size file already saved in the container the speed drops.
Ok.
I don't use TrueCrypt, so I have no hands-on experience here. The encryption and container management is happening on the PC, the NAS is only supplying block storage (similar to an iSCSI LUN in that respect). One puzzle here is sorting out what the PC overhead actually is. It likely depends on whether the PC supports hardware accelerated encryption (or not).
You could create a TrueCrypt container on the PC, and see what performance that gives you. If you have a second PC, you could try sharing the folder that container is in with Windows Filesharing, and compare that performance with the container on the NAS.
The initial burst of speed at the beginning of the measurement is likely a caching side-effect, your sustained speed is the real speed.
This issue was introduced in ReadyNAS 6.9.0 and is still present in 6.9.1 (Just released). When performing writes to a TrueCrypt container that is on an SMB share with Snapshots off, COW disabled, File search disabled and antivirus disabled the performance drops to very low levels (15Mbit/s) and the HDD is actively thrashing about (a lot of noise due to the drive heads seeking). I reverted to 6.8.1 (while I know is not recommended) and the issue went away. So this is a new issue introduced with 6.9.x. In my case there are no connection or HDD issues, transfers outside of the truecrypt volume appear to be ok. Also it only appears to apply to writes to the truecrypt container as reads, at least my case, appear to be ok.
I was in the middle of doing a systematic test of every hard drive and combination of writing to containers (on and off the NAS). Common denominator was that everytime i'm writing to a container on the NAS the speed is too slow to use. I wonder if this is going to be fixed in a future update? What are the issues in reverting back to 6.8.1?
I can confirm this behavior, but I can't explain it. I have two Pro2 units, one running OS6.9.1 and the other 6.8.1. but otherwise similarly configured. I created a 200GB static VeraCrypt volume on each NAS in a share where CoW and snapshots are disabled. Veracrypt running in Windows, not on the NAS. I did a Windows drag-n-drop copy of about 40GB of photos and videos in multiple folders/subfolders to each. Time to complete with the Veracrypt volume on OS6.9.1 was 5 hours. Time to complete with Veracrypt volume on 6.8.1 was 21 min. Time to just copy the folder to the share itself with OS6.9.1 was 30 min. All operations used the same PC on a home network with nearly no other traffic.
The PC and NAS CPU and network usage were much higher on the actions that were the fastest, so clearly it is the access to the file itself that's the bottleneck, with it acompinied by a lot of disk "thrashing". SMBD was at 50% for the direct copy, 40% with the Veracrypt volume under 6.8.1, and 3% with the Veracrypt volume under 6.9.1. But nothing else was eating up the CPU.
So, I decided to see what would happen with a static .VHD container under 6.9.1, and the results were similar to the VeraCrypt volume under 6.8.1.
I have no idea what aspect of 6.9.x is causing this, but something sure is different that is used by Veracrypt/Truecrypt but not much or at all with a .VHD container or normal file storage.
The GUI definately says CoW is off. Is there another way to confirm that? Maybe that's the issue, but I would expect that to have similar effects on both container types. No encryption enabled except that Veracrypt is encrypting on the PC before storing.
As for fragmentation, filefrag says the Veracrypt container has 1277 extents and the .VHD has 14212 on the 6.9.1 system.. The Veracrypt one has 796 on the 6.8.1 system and I dind't do a .vhd on it. I find that number of extents on the .vhd very odd, as it was created after the Veracrypt one and there should have been plenty of space to be mostly contiguous.
For my use, I can probably move to .vhdx files (though I didn't check that yet -- only checked .vhd). I have always used TrueCrypt/VeraCrypt ones because they are more robust than .vhd. But .vhdx is supposed to fix that and I no longer have a need to access them from Win7. But for anyone that actually needs encryption or access by something other than Windows 8+, that's not an alternative.
The GUI definately says CoW is off. Is there another way to confirm that?
lsattr will tell if it is off for a specific file (the "C" attribute is set if CoW is off - backwards from what you might think).
If it isn't set, try creating a subfolder from ssh, and then set +C on the subfolder with chattr. Then copy the container into the subfolder. C should be set on the copy.
OK, so I created a BitLocker encrypted .vhdx file and it also works without the issue. So for those using Windows 8 or 10, Pro or Enterprise versions only, this is an option. There are not all of the command-line options to do the mounting via a batch file, though, as there are in VeraCrypt.
If you don't need encryption, then you can use lesser versions of Win 8/10. If you need to have access from Win7, you can use a .vhd instead of .vhdx. Win7 Ultimate does support BitLocker, but I don;'t know if it was ever updated to allow for encryption not tied to the computer, as I have never had Ultimate.
My understanding is that Win 8/10 Home can access a BitLocker encrypted drive, just not create one. But what that means if you write to it, I don't really know. I also have no Home versions.
Ideally, though, what causes this needs to be determined and eliminated.
I wonder if @Skywalker has anything to say on this.
Yes, the difference is the default sync policy. Every prior version of Samba that we have used ignored sync requests from SMB clients by default. That has changed in Samba 4.7.0, which was included in 6.9.0. See the Samba wiki for details.
You can change that setting manually by running:
# echo strict sync = no >> /etc/frontview/samba/smb.conf.overrides
from an SSH session. I'll see if we can get this option added to the GUI in a future firmware release.
Is there an easy way to do this? I'm not great at following how to change this setting.
He already provided the easiest way.
First enable ssh on your NAS from the web ui (system->settings->services page).
If you have a mac, you can connect to the NAS with terminal. You open terminal, then type ssh root@NAS-IP-ADDRESS. After you enter this, you'll be prompted for a password. Use the NAS admin password.
I have a new local build of the SMB Plus app that adds an option for this setting. Get it from here, and install from the Apps tab, using the Upload button. Then launch the SMB Plus app, go to the Write Options tab, and disable Strict Sync.
We plan to make this a per-share option in a future firmware release.
