Re: Image Catalog over NFS

Hello Diego,

Am 10.12.2024 um 17:31 schrieb Diego E. KESSELMAN <diegokesselman@xxxxxxxxx>:

Sorry, I was not clear. I usually save this to an Optical Remote Image Catalog , and the remaining data , using Option 23, to a Virtual Tape Image Catalog (using local disk), when migrating IBM i to the cloud, or backing up data from On-Prem to the cloud.

I see. Apparently you have a completely different use case. :-)

However, I know that NFS over UDP is much more sensitive to network latency, compared to TCP. It was once common knowledge to never run NFS across routers, because the routers in the late 1980's introduced quite a few ms of latency.

I have found that NFS V3 over UDPs needs a lot of RAM and CPU to work properly.

TCP uses checksums. For UDP, they're optional. CPU usage should be less, and memory usage about the same. Which platform are we talking about?

I have compared copying a file with NFS vs SCP and FTP. And when using iSCSI (VTL) for saving, the difference is evident.

From my experience, FTP wins in terms of performance, in LAN environments. No crypto as with scp, just data shoveling.

Scp allows online compression (with -C) though, which might be beneficial with compressible data. Not as efficient as local compression with a tool of choice, but completely transparent for both peers.

Only NFS allows direct access to files in a remote location. FTP and scp are for data duplication over the network — creating a copy.

VTL driven over iSCSI is again a completely different beast, because it's block oriented.

This observation can base on many reasons and side effects, not just UDP being (perceivably) inferior. In addition, comparing iSCSI — being a block oriented protocol — with NFS — being a file oriented protocol — seems to me a bit like comparing apples to oranges.

If you compare NFS V3 with UDP vs NFS V4 or V4.1 with TCP, there is a big change.

I probably need to retest this. My latest experiences were comparing NFSv3 vs. NFSv4 over TCP in a VMware ESXi environment, for presenting the virtual disks to the hypervisor hosts. NFSv4 introduced a performance hit I have not found an explanation for. Maybe a peculiarity of ESXi…

Unfortunately you cannot use NFS V4.x over TCP for remote install your IBM i.

More precisely, you can't use tcp at all and the client within the service adapter code negotiates a NFSv3 connection. According to the docs.

I know it's like comparing rocks and trees, but both are used for the same purpose: Network Backup/Restore

Well, it's still rocks and trees, just as you say. Just like you'll probably fail to plow a field with a Porsche car, compared to a tractor. Both have four wheels, so they serve a similar purpose: Move things…

The Kernel-NFS-Server is one option, but there are other NFS servers available.

I'm aware. Because they run in user space, they're somewhat less favorable in terms of performance. I admit that this is hearsay I've picked up decades ago.

We don't use backup to NFS regularly, only on migrations.

I see. Completely different use case. I need a backup solution without any additional hardware

When running in the cloud the Option 21 lose its value, because you have snapshots, clones and exports. We usually save to local disk and upload to S3 buckets once we have compressed everything.

Cloud is something I stay away from. Time has shown that essential promises of the cloud hype have been proved wrong over time. Maybe this is typical German trait, but my data stays under my responsibility. No cloud. Period. :-)

Our next challenge is to compress with a second job monitoring media changes, so we can reduce the amount of data on disk, improve compression ratio and improve backup job times.

Good luck with that! Linux+GNU as a complete OS has… is a rich toolbox for that but I fail to understand if this is applicable to your use case.

But your mentioning of VTL is an interesting remark. Will set up another message to the group.

:wq! PoC