2

Recently I had a file that reported a file size of 33P bytes in my 500GB SSD, more details here. That was through ls and cp would report that there was no enough space.

In my short knowledge and poor understanding of VFS, I would believe that the (SATA) drivers talk to the disk and it moves its way through the VFS until it makes it to the inodes (assumption from the description on section 8.6 Inodes here) and then the kernel somehow pass it to user space.

In the end, I like to know how ls and cp know the size, but I would also like to know how a file could report the wrong size and if it were to happen again in the future, where to look for answers.

user3325563
  • 41
  • 3
  • 3
    Note: 36028797019011568 is 2**55 + 47600. It's reasonable to guess that the correct size is 47600, and there is a single corrupt bit. You should run a full fsck on it (e.g. `e2fsck -f` if it's ext2/ext3/ext4) to search for other errors. –  Aug 24 '17 at 21:13

2 Answers2

0
strace -v -e trace=lstat ls -l file
[...]
lstat("tw.txt", {[...] st_size=1103, [...]
Hauke Laging
  • 88,146
  • 18
  • 125
  • 174
0

The size of a file is stored as part of the file's metadata, alongside the file type (directory/regular/symlink/…), the timestamps, the permissions, etc. Applications retrieve this metadata with the stat system call. The metadata is stored in the file's inode.

The SATA driver is involved if the file is stored on a SATA disk but that's a much lower level than the filesystem. Taking the SATA level into account won't help you understand what's going on, quite the contrary.

It's possible for a file to be larger than the disk. A file can be compressed. Most filesystems only support one very simple form of compression: sparse files, where large blocks of null bytes are not stored on the disk. The disk usage reported by du does not count those omitted blocks, but the size of the file reported by ls does.

As Wumpus Q. Wumbley notes in a comment, the size you found (36028797019011568) is one bit off from being a perfectly reasonable size (47600). So it's likely that rather than being a legitimate sparse file, this size is a sign of data corruption on the disk. Before you do anything else, run a memory test. RAM is the biggest source of uncorrected single-bit errors. Beware that it's likely that you have more corrupted data due to this error.

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175