Spectrum Protect backup of massive sparse file /var/log/lastlog on linux

From the customer:

I found five RedHat-based Linux clients that were ultimately waiting for tape mounts because they were trying to back up the massive sparse file /var/log/lastlog. This file reports as being 480GB in size, even though it is actually a small file in content. But since TSM has to reserve space on "face value", regardless of file type, this means it exceeds the MAXSIZE parameter of our dedupe pool and goes to tape. Get a few dozen of these running simultaneously and all tape drives are committed! This is a known issue that is not unique to TSM, and if you Google on "lastlog Linux backup" you can see not only others reporting the same issue but apparently RedHat developers seem to be ignoring the problem. How can you have a 480GB file located on a server that only has a few Gigabytes of total storage? It doesn't make sense.

So I'm applying an Exclude parameter to the five clients and we're looking at how to roll this out to the rest of the RHEL clients with Unix support.

Meanwhile, I appreciate that IBM shouldn't have to be in a position to fix other vendors' problems, but this is a potential deadly problem, and it pertains to sparse files in general, which aren't unique to RedHat. Having some built-in intelligence should be mandatory for TSM as a backup product. For example, if TSM detects a sparse file, why not fetch the directory value that identifies the true file size? And if not that, pre-screen these files and reserve space on the TSM server accordingly? TSM already handles the restore/retrieve of sparse files in two different configurable ways, so there is already precedence.