TrueCrypt container

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.

Perhaps check with ssh to see if the container is fragmented.  Maybe also confirm the CoW is really off?

Is the NAS using encrypted SMB3 on the container's share?

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.

---

Sandshark wrote:

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.

Just checked, and the "C" attribute is there.

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.

This resolved the issue for me, Thanks.

Works here, too.  Does require a reboot, which was not stated by Skywalker.

Reading the Samba wiki, though, this sound more like something Veracrypt should change, if possible; as using strict sync seems like a good idea.

Hi Skywalker

Is there an easy way to do this?  I'm not great at following how to change this setting.

---

McGarnagle wrote: 

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.

If you have a windows PC, then download putty from here: https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html.  Access the NAS with putty (selecting ssh).  Use root as the username, and the NAS admin password.

After you log into the linux shell successfully, enter the command that skywalker gave you at the # prompt.

echo strict sync = no >> /etc/frontview/samba/smb.conf.overrides

---

Skywalker wrote:

 

We plan to make this a per-share option in a future firmware release.

---

Great!  That'll give mne the best of both worlds.  I can disable it for my backups share and enable it everywhere else.  I'm still going to see if the IDRIX folks can do something about it in VeraCrypt..

Unfortunetely this does not work for me.  I installed the SMB Plus app and ensured the Strict Sync was disabled (it was already set to disabled before i checked).  Then i reset the NAS.
However, the original problem has not changed.  Is there something that i could be missing?

It doesn't make sense that Strict Sync would have already been set to disabled, unless you ran the command I posted earlier from a terminal.  Maybe there's some strange browser issue with the SMB Plus app?  In any case, I can take a look to confirm that the proper setting is in place if you enable Secure Diagnostic Mode and PM me the 5-digit number.

Hi SkyWalker

I did a little more checking.  It appears that the problem only persists for TrueCrypt 7.1a containers.  VeryCrypt containers seem to work ok.  I don't know if this makes sense but its probably good enough for me since i can simply make VeryCrypt containers and move everything there.

Actually, spoke too soon.  I was looking at the wrnog thing.  Looks like the problem persists for all containers.  SkyWalker ive PM'd you the 5 didgit code as suggested.

The strict sync setting looks good, but I see you've got the max protocol set to SMB1.  SMB3 is much more efficient.  Can you switch to that and then try some SMB transfers?  I can monitor the system operations during the transfer to see where the bottleneck is.