rsync
rsync copied to clipboard
rsync: link "…" => … failed: Too many links (31)
Like many people, I am using rsync with --link-dest to create hard-linked efficient backups.
I've run into the infamous 65K directory entry limit of ext4 however and am getting the following error from rsync:
rsync: link "/.snapshots/daily.0/pvr/usr/share/jellyseerr/node_modules/.pnpm/@[[email protected]](mailto:[email protected])/node_modules/@formatjs/intl-listformat/locale-data/ff-Adlm-GW.d.ts" => usr/share/jellyseerr/node_modules/.pnpm/@[[email protected]](mailto:[email protected])/node_modules/@formatjs/intl-displaynames/locale-data/af-NA.d.ts failed: Too many links (31)
Hlink node data for 89181 already has path=usr/share/jellyseerr/node_modules/.pnpm/@[[email protected]](mailto:[email protected])/node_modules/@formatjs/intl-displaynames/locale-data/af-NA.d.ts (usr/share/jellyseerr/node_modules/.pnpm/@[[email protected]](mailto:[email protected])/node_modules/@formatjs/intl-listformat/locale-data/ff-Adlm-GW.d.ts)
rsync error: errors with program diagnostics (code 13) at hlink.c(543) [generator=3.1.3]
rsync error: received SIGUSR1 (code 19) at main.c(1447) [receiver=3.1.3]
It seems to me that in such a case, a fall-back to just creating a new (albeit inefficient) copy of the file would be the most data-safe path to take. Perhaps with a warning of some sorts.
In researching, I came across #329 where the OP reports:
ext4 supports a maximum number of 65000 hard links per inode.
When this is exceeded and rsync tries to create another hard link, it falls back to copy.
But clearly I am not experiencing that fall-back to copy. Have I run into some kind of bug with that feature here?
FWIW, I am using rsync version 3.2.3 on the source (where the file is being copied from) and 3.1.3 on the destination (where the file is being copied to and where the rsync command is being driven).