Comment 4 for bug 1375640

1) e2fsck (which is what fsck.ext[234] is hard linked to) is designed to be safe when getting interrupted by ^C

2) The all kernel code uses the same address space. So if there is a wild pointer in the Nvidia driver scribbles on random kernel memory, literally anything can happen. There is a reason why upstream kerenl developers will generally refuse to debug a kernel crash where the kernel is "tainted" by using a proprietary closed source kernel module. The kernel oops has a taint flag specifically because buggy video drivers in particular have historically been responsible for a huge number of failures that were at first not obviously related to the video driver, and upstream kernel developers wasted a lot of time before concluding: try again without any closed source modules loaded; we refuse to debug a tainted kernel.

And before you ask why not put the Nvidia driver in a separate address space --- Microsoft tried this a long time ago with the version of Windows NT --- and the resulting video performance was sooooo awful that the first version of Windows NT was a complete failure, and they had to reverse course and allow video drivers to run in the same address space. Linux cares about performance as well, and besides, we have zero interest in enabling crappy closed-source drivers, especially those from video card companies. Personally, I use laptops with Intel video chips, since that allows me to use 100% open source kernel.

3) It may be possible to recover the data by using e2fsck and debugfs, if you can find someone with ext4 skills who is willing to give you some free consulting time. Alternatively, you can try using photorec, which is one of the better tools for scanning the raw partition and finding and recongizing various data formats. It was originally designed to find image files (hence photorec), but it has since been extended to support a huge number of document types, including Libreoffice, Microsoft Office, etc., etc.