Synology NAS - iSCSI - ReFS

[Nick-SAC]

Synology DS918+ running DSM 6.2.2-24922 Update 2

Either I’m missing something or the newer versions (apparently 6.2 up) of Disk Station Manager (DSM) have eliminated the ability to configure an iSCSI attached ReFS Formatted Volume.

There used to be an item in the DSM Storage Manager to a Create a Block Level iSCSI LUN (which would then be located directly on the iSCSI Target Storage Pool ) but that’s no longer there and in the new iSCSI Manager it will only let me create a LUN on a previously created (BTRFS formatted) Volume.

Curiously, if I do that; when I establish the iSCSI Connection to the Windows Server (2019) Windows appears to let me format it as ReFS (I’ve only tried a Quick Format) but the Volume still shows as BTRFS from within DSM – and I can’t even venture a guess as to what that means?! ... Or how it will or won’t work?!

FWIW, I’ve got 2 other Synology NAS units (a DS918+ and a DS412+) which were configured under DSM 5.2 or 6.1 with the iSCSI LUN Located directly on the iSCSI Target Storage Pool (no Volume exists on the NAS) and they’re still working fine even though they’re also now running DSM 6.2.2-24922

I’ve just opened a Support Ticket with Synology on this and will report what I find out... but if anybody has a suggestion, I’d love to hear it!

[Nick-SAC]

I haven’t received a response from Synology yet but in the meantime...

I’m currently experimenting by performing a Full (not Quick) ReFS Format from the Win2019 Server on the iSCSI attached Target/LUN which is (as seen from within DSM on the NAS) a BTRFS Formatted Volume.

Does anybody know if this ReFS/BTRFS scenario will work and/or if it is an advisable or even supported configuration?

[Nick-SAC]

Here is the response from Synology...

================================->snip<-================================

The luns which were directly on the storage pool were known as block level luns. After DSM 6.2, our developers removed the option to create block level luns. Once which previously existed will continue to work.

The block level luns did not perform as well as file level luns, so you should actually be better off with a file level lun. We would recommend making sure you are on the latest version of DSM, creating a btrfs volume, then create a thick provisioned file level lun with the default features chosen. We recommend not creating luns which consume more than about 90-95% of the volume to prevent the possibility of the volume filling to capacity, since the system does need some space on the volume for system files and general operation, and also it is possible for a lun to consume slightly more than the allocated amount due to any fragmentation.

You mentioned "it will need to be formatted ReFS but on the NAS the Volume that the LUN would be on is BTRFS and that (even if it would appear to work) seems like it'd be asking for trouble..."

This shouldn't be asking for any trouble. The NAS just obeys the commands from the iscsi initiator, it does not actually read the data or even know what filesystem is on it, or if there is a filesystem on it at all. So the choice of filesystem will make no difference on a block or file level lun.

Sincerely,
Carl W
Synology Tech Support

================================->snip<-================================

Frankly I’m not entirely comfortable with this BTRFS/ReFS issue but it seems to be working properly so far in as much as the Full ReFS Format from the Win2019 Server proceeded without error (although it took 18 hours for a 10TB Volume over a 1Gbps LAN).

After I get some VM’s in place on this Server and do some Backups & test Restores I’ll report the results but I’d still welcome any input from someone more well versed than I in the FS issues.

[GT-Engineer]

NIck-SAC

I am looking into this type of configuration now, because of the performance gains. Did you see any performance gains and is it stable?

[Nick-SAC]

I haven't seen any stability issues at all but then again VBR may be the most bulletproof piece of software I've ever had the pleasure of working with!

I haven’t done any hard-core Controlled A/B testing... but just in looking at the reports of some otherwise very similar systems, I can’t really see any difference in the VBR Backup performance between the Block Level/ReFS and the BTRFS/ReFS NAS Device Repos.

That said, these are very lightly loaded Servers & running 7200 RPM HDDs as RAID-1 Volumes and so, even with the NAS only using a single GbE Port, the Bottleneck is almost entirely the Source. If one had 15,000 RPM HDDs on a RAID-5 Volume using both GbE Ports the results might reveal significant or even dramatic differences between the NAS Block Level vs. BTRFS Volumes.


Nick

[mathieu.pierluigi]

Hello Nick,

I'm really glad to see you have almost the same configuration as mine, and say that it is working well.

My set up: a 50 Btrfs TB volume is presentend via 1Gbps iSCSI to a fully patched physical Windows 2016 which is also proxy, and the volume is then formated in Refs 64K.
(Cumulative update 01/2020 - 20 CPU core and 64 GB of RAM)

I have currently issues:
- Backup starts with a good speed (200 Mbps).
- Then, data flow drops to 0 during backup, after having treated his first vmdk.
- At this moment, the RAM on the server is really high (36 Go) and drops untils 5 GB and then the backup resume.
- The scenario repeat for each vmdk treated with variable breaks and so the job curve is shaped like a sawtooth.

I have already opened a case which told me to change the server for a newer, still the same problems.

I tried to change some reg keys, job options, VBR server, NAS, proxy, older refs drivers without success.

If someone have an idea.

Thanks for help.