Re: Image Catalog over NFS

in V7.5 NFS defaults to TCP according to the memo to users.
since you are at still at 7.3, I doubt you could add "tcp" to the end of the "options" parm.

the API mentioned below is intersting, although it does not appear it can "force" NFS to use TCP, just NFS versions.

NFS mount options default to TCP protocol
The Network File System (NFS) mount options will now default to use the TCP network transport protocol to communicate with servers. The IBM i NFS client requires that the NFS block input-output daemon is active when an NFS file system using TCP is mounted or accessed. NFS users will need to start the NFS block input-output daemon with STRNFSSVR SERVER(*BIO) before establishing NFS mounts when the default mount options are used.
Users can return to prior release behavior by adding the 'udp' option to the ADDMFS or MOUNT command options string. The switch that was provided to enable TCP support in the NFS client with the QP0FPTOS API *NFSFORCE option in prior releases will no longer affect NFS client behavior. The ADDMFS or MOUNT options must be used instead

Bryan


Patrik Schindler wrote on 10/21/2024 11:54 AM:

Hello,

Am 20.12.2020 um 17:22 schrieb Patrik Schindler <poc@xxxxxxxxxx>:

I wonder if one can save time and unnecessary network traffic by not writing a file full of zeros, but create a sparse file. Instead of

dd if=/dev/zero of=IMAGE01.ISO bs=1M count=10000

do a

dd if=/dev/zero of=IMAGE01.ISO bs=1M seek=10000 count=0

See https://en.wikipedia.org/wiki/Sparse_file for details.

I did not test if IBM i can cope with sparse files, but I don’t see any reason why it shouldn’t.

Today I finally managed to get image catalogs for save/restore to eventually work on a 7.3 machine.

Using sparse files works like a charm. No needless I/O on the NFS server for allocating Gigabytes of zeros. No extra space being consumed because of needless zeros.

Alternate command to create such an empty file:

truncate -s 30G backup.udf

echo "backup.udf W" > VOLUME_LIST

The "W" is important. Without it, the image catalog will be read-only.

For me, I stick to the already established ftp workflow. The backup server uses jumbo frames, while the E4A isn’t configured for them. So, UDP (NFS) answer packets will be lost in transit and NFS doesn’t work. Mount and un mount work, though.

This is what I've forgotten and rediscovered today. I hereby thank my older self for his help to solve this mystery. ;-)

I did not try if NFS can be forced over TCP in IBM i.

According to the documentation, it's not possible.

In 7.3, the service tools adapter MTU cannot be configured.

No easy way out here.

:wq! PoC