If a Linux Stage 1 Sync or a Host Sync fails with:
RSP_SYNC_ERROR SYNC_ERROR_TRANSFER STATUS_ERROR
Details: read errors mapping <file name>: No data available
action will likely be needed on the source host.
There are 3 reasons why this may have happened:
1) The file system being sync'ed is not using LVM, and Allow Direct Fscopy is being used implicitly.
2) The Allow Direct Fscopy option may have been set on the GUI. If so, remove this setting, so the option is no longer selected on the GUI. In general, the use of allow-direct-fscopy is not recommended
3) There are inadequate free extents on the source server, even though the number of free extents on the source server is already equal to 15 percent of the Used Space on each logical volume (which is the default). A small set of servers change so rapidly that the number of free extents recommended by default (15% of the Used Space ) is not enough. Issue the 'rw host show <source hostname> command to see the number of free extents available for each volume group on the server. In particular, look at the number of free extents for the volume group that contains the logical volume mentioned in the error. If that volume group already has 15% of the Used Space in free extents, please add another 5% in free extents.
The easiest way to determine if a file system is using LVM or not is to issue the 'rw host show <source hostname>' command. A snippet of sample output of that command is shown below.
[root@rmm-c1 opc]# rw host show centos7-src
Host Name : centos7-src
Host IP : 62.105.92.107
Host State : Discovered
Examine Date: Wed Jun 24 20:49:50 2020
OS Type : Linux (64-bit)
OS Version : CentOS 7.0
OS Name : CentOS Linux 7 (Core)
Username : root
LVM Volume Group : centos
Number of LVs: 2
VG Size : 15.5107 GB
Free Extents : 0 Bytes (0% of size, 0% of used)
File System : centos/root [ ROOT ]
Type : xfs
Size : 13.9062 GB
Used : 1.13555 GB
Free : 12.7707 GB
Mountpoints : /
UUID : f04f7244-ede9-4097-b72b-2f9b30f63b47
Block Size : 4 KB
Volume : /dev/mapper/centos-root
Volume Type : LVM Logical Volume
LVM VG Name : centos
LVM LV Name : root
File System : centos/swap
Type : swap
Size : 1.60156 GB
Used : 1.60156 GB
Free : 0 Bytes
Mountpoints : swap
UUID : b970056b-832c-4d3a-9414-eb2717349d34
Block Size : 4 KB
Volume : /dev/dm-0
Volume Type : LVM Logical Volume
LVM VG Name : centos
LVM LV Name : swap
File System : /dev/sda1 [ BOOT ]
Type : xfs
Size : 500 MB
Used : 99.1406 MB
Free : 400.859 MB
Mountpoints : /boot
UUID : 67c2989a-f6ac-43bd-befe-47f8acde3a83
Block Size : 4 KB
Volume : /dev/sda1
Volume Type : MBR Primary Partition
Based on the output, this must be case 2. The output shows that the file systems do have a volume type of 'LVM Logical Volume', and information about the LVM Volume Group is shown - and there are 0 bytes of free extents on this volume group. If a sync were attempted of this server without --allow-direct-fscopy it would fail with
RSP_SYNC_ERROR SYNC_ERROR_INSUFFICIENT_ORIGIN_FREE_EXTENTS STATUS_ERROR
Details:
Not enough LVM free extents in VG centos to take a snapshot of LV root (requires 197132288 bytes)
So possibly allow-direct-fscopy was used to work around the lack of free extents.
The proper course of action in this case is to add free extents to the volume group "centos" and then run the sync without having the Allow Direct Fscopy option selected.
If the file system being sync'ed is not using LVM volume groups (the first case) , then the 'rw host show <source hostname> ' output will be different.
[root@rmm-instance-01 opc]# rw host show centos6-Src
Host Name : centos6
Host IP : 10.11.21.33
Host State : Syncing
Examine Date: Fri Jul 03 04:20:44 2020
OS Type : Linux (64-bit)
OS Version : RHEL 6.10
OS Name : Red Hat Enterprise Linux Server release 6.10 (Santiago)
Username : rackware
File System : /dev/sda3 [ ROOT ]
Type : ext4
Size : 262.875 GB
Used : 90.0292 GB
Free : 172.846 GB
Mountpoints : /
UUID : 49875dfb-9825-49f4-afe9-d1f0cbf37624
Block Size : 4 KB
Volume : /dev/sda3
Volume Type : MBR Primary Partition
File System : /dev/sda2
Type : swap
Size : 16 GB
Used : 16 GB
Free : 0 Bytes
Mountpoints : swap
UUID : 7f73c62c-aee4-4b4b-86b1-ab8166448e9e
Block Size : 4 KB
Volume : /dev/sda2
Volume Type : MBR Primary Partition
File System : /dev/sda1 [ BOOT ]
Type : ext4
Size : 500 MB
Used : 124.535 MB
Free : 375.465 MB
Mountpoints : /boot
UUID : f2d7791c-b857-4aa8-ae55-c6c1a03e6f99
Block Size : 1 KB
Volume : /dev/sda1
Volume Type : MBR Primary Partition
Note that in this case the Volume Type is 'MBR Primary Partition' rather than 'LVM Logical Volume', and that there is no information block showing any LVM Volume Groups. If file systems are not using LVM Logical Volumes, then LVM snapshots can not be used. So the RMM will use --allow-direct-fscopy for the sync.
The best course of action in this case would be to convert the root file system above to an LVM volume on the source host, and be sure it has adequate free extents.
When using allow-direct-fscopy, you may see that Stage 1 Syncs or Host Syncs work some of the time, but at other times the sync fails with the 'read errors mapping' error. This is all a matter of timing with respect to if or when files being transferred are getting modified. The rate of change of files in a file system will also influence if allow-direct-fscopy will work or not; in general, file systems containing just the OS don't have a high rate of change, while file systems containing data do have a high rate of change. So allow-direct-fscopy is more likely to work fine for OS file systems than for data file systems.
RackWare's recommendation is to not use allow-direct-fscopy, but to use LVM and have adequate free extents for all LVM volume groups.