Restored file is 4.0 EB big about xfs_undelete HOT 3 CLOSED

Such extraordinary huge files are likely bogus. The only valid reason to have such a file is that it is sparse. That means, it consists of zeroes mostly. Pretty much only databases and tools as bittorrent which combine several source files in place create valid files of that sort.

from xfs_undelete.

Hi,
I managed to extract the relevant data from that file. It was on the first 16606 lines. Using sed or vim was a no go, they filled up the memory and got killed. I managed to extract the data using head -n NNN and try&error to guess the number of lines.

You may want to close this issue as solved, but isn't there an option to avoid this huge files? How can a file be bigger as the underlying FS? Why does -z not work here?
Anyhow, many thanks for xfs_undelete, nice work!

Thanks,
Richard

from xfs_undelete.

There's already a lot of sanity check in xfs_undelete. The one that usually triggers is that those huge bogus sparse file often have no data at position 0 and following. But yours had. I don't know.

How can a file be bigger as the underlying FS?

It's a sparse file. It does not occupy that space on the original filesystem. You have to think of it as e.g. one block at position 0 and another block at position 18446744073709551616. It only takes 8192 bytes on disk then.

Why does -z not work here?

Because -z does only delete zeroes at the end of a file, not zeroes inbetween. Oh, and it has the same problems with huge files as vim and sed.

from xfs_undelete.