I haven't ever run an iSCSI setup, but...

I don't know what your application is, but if you're planning on running a MySQL database on this, I can imagine that a throughput test isn't going to be representative of your performance, since latency may matter a lot and throughput not so much. You may want to specifically test that.

ponders

I would guess that iSCSI probably exposes write barriers. That is, btrfs can say "all writes prior to this point must become durable before writes subsequent to this point", without actually requiring that any data is committed to the disk at the time that the write barrier is issued.

But I believe that the Linux file API has a more-limited set of ways in which it can provide ordering without durability. There's no fwritebarrier(), just fsync(), and that forces a change to become durable.

Depending upon how MySQL works, that might have a significant impact on performance.

Also, NFSv3, which I assume you are using, has behavior around locking and caching that differs from NFSv4 and I don't know for sure how it will interact with something like MySQL, which may care a lot about precise write ordering behavior.

Disk images will also rely on write ordering to avoid corruption on power loss.

googles

Yeah.

https://dev.mysql.com/doc/refman/8.2/en/disk-issues.html

Using NFS with MySQL

You should be cautious when considering whether to use NFS with MySQL. Potential issues, which vary by operating system and NFS version, include the following:

• MySQL data and log files placed on NFS volumes becoming locked and unavailable for use. Locking issues may occur in cases where multiple instances of MySQL access the same data directory or where MySQL is shut down improperly, due to a power outage, for example. NFS version 4 addresses underlying locking issues with the introduction of advisory and lease-based locking. However, sharing a data directory among MySQL instances is not recommended.

• Data inconsistencies introduced due to messages received out of order or lost network traffic. To avoid this issue, use TCP with hard and intr mount options.

• Maximum file size limitations. NFS Version 2 clients can only access the lowest 2GB of a file (signed 32 bit offset). NFS Version 3 clients support larger files (up to 64 bit offsets). The maximum supported file size also depends on the local file system of the NFS server.

Using NFS within a professional SAN environment or other storage system tends to offer greater reliability than using NFS outside of such an environment. However, NFS within a SAN environment may be slower than directly attached or bus-attached non-rotational storage.

If you choose to use NFS, NFS Version 4 or later is recommended, as is testing your NFS setup thoroughly before deploying into a production environment.

That's kind of hand-wavy, but it does reinforce my concern about sticking a MySQL database on the thing.

I don't have an answer for you as to which to use -- it's been a while since I've worked on network filesystem stuff, and I'm kinda shaking loose rusty bits trying to recall this -- but in general I would be a little concerned about data integrity of both disk images and MySQL databases stored over a network. One can build a system that does it correctly, but I would try to do what I can to research potential issues there.

I would also probably test your actual workload if you're concerned about performance, because it may differ a lot from what a simple throughput test might suggest for those uses.