Comment 2 for bug 1375640

You're jumping to conclusions here that the damage was caused by the lack of "-t ext4" to fsck. #1, the fsck program will determine the file system type based on the file system type found in /etc/fstab. So if the /etc/fstab file indicates that you were using ext4, then it wlil do the equivalent of running "fsck -t ext4". #2, even if that was wrong, all that would have happened was the wrong fsck program would have been called. If it was really a btrfs or xfs file system, it would have run fsck.btrfs or fsck.xfs, and they would have rejected the file system as not a btrfs or xfs. If the /etc/fstab wrongly thought it was a ext2 or ext3, then fsck would have run /sbin/fsck.ext2 or /sbin/fsck.ext3 --- but /sbin/fsck.ext* are all symlinks to the same program, /sbin/e2fsck. So it wouldn't have made a difference.

So the "severe file system damage" had nothing to do with the use or lack thereof of "-t ext4", but rather because the file system was badly damaged by the Nvidia-induced crash. If the closed source kernel module managed to scribble on kernel memory, it could have caused metadata blocks to be written to the wrong place on disk, or corrupting critical metadata blocks. Or if you had to hard power cycle the system, and you were using a SSD that doesn't have power fail protection (most consumer grade SSD's don't), then that might also explain the severe file system corruption.