> Not sure why you would carry around metadata the filesystem is already tracking for you.
Because bmap files are independent of the filesystem and OS, and thus would probably like to work even with filesystems which don't support sparse files, and OS which don't expose holes?
For instance until NFS 4.2 in 2016 you could write sparse files to an NFS volume, but there was no way to detect holes when reading. exfat doesn't support sparse files at all. And according to their man pages, OpenBSD and NetBSD have yet to support SEEK_HOLE/SEEK_DATA (which are non-standard extensions of POSIX lseek(2)).
Plus according to its history the bmaptools project was created about a year after the release of kernel 3.1, which introduced support for SEEK_HOLE and SEEK_DATA. Doesn't take much of a leap to assume that the project's creator didn't consider that widespread enough to be reliable (Debian wouldn't release a 3.x-based version until the following year).
Seeking through holes also doesn't work very well for compressed images, since usually there is no way to tell apart an insignificant hole from a long sequence of zeroes or other filler data.
Because bmap files are independent of the filesystem and OS, and thus would probably like to work even with filesystems which don't support sparse files, and OS which don't expose holes?
For instance until NFS 4.2 in 2016 you could write sparse files to an NFS volume, but there was no way to detect holes when reading. exfat doesn't support sparse files at all. And according to their man pages, OpenBSD and NetBSD have yet to support SEEK_HOLE/SEEK_DATA (which are non-standard extensions of POSIX lseek(2)).
Plus according to its history the bmaptools project was created about a year after the release of kernel 3.1, which introduced support for SEEK_HOLE and SEEK_DATA. Doesn't take much of a leap to assume that the project's creator didn't consider that widespread enough to be reliable (Debian wouldn't release a 3.x-based version until the following year).