2

The computer was working fine until this morning I found out the hdd (two 4TB disk in RAID0 made with mdadm) had Input/output error.

Upon lsing the directory, I was met with:

ls: reading directory '.': Input/output error

And further inspection on dmseg shows that accessing my disk md127 causes some warnings and errors:

[5789751.027967] EXT4-fs warning (device md127): htree_dirblock_to_tree:994: inode #184288528: lblock 2: comm rg: error -5 reading directory block
[5789751.027970] EXT4-fs warning (device md127): htree_dirblock_to_tree:994: inode #184288528: lblock 2: comm rg: error -5 reading directory block
[5789751.027973] EXT4-fs warning (device md127): htree_dirblock_to_tree:994: inode #161822641: lblock 7: comm cp: error -5 reading directory block
[5789751.027975] EXT4-fs warning (device md127): htree_dirblock_to_tree:994: inode #184288528: lblock 2: comm rg: error -5 reading directory block
[5789751.027976] EXT4-fs warning (device md127): htree_dirblock_to_tree:994: inode #184288528: lblock 2: comm rg: error -5 reading directory block
[5789751.027979] EXT4-fs warning (device md127): htree_dirblock_to_tree:994: inode #184288528: lblock 2: comm rg: error -5 reading directory block
[5789751.027982] EXT4-fs warning (device md127): htree_dirblock_to_tree:994: inode #184288528: lblock 2: comm rg: error -5 reading directory block
[5789751.027986] EXT4-fs warning (device md127): htree_dirblock_to_tree:994: inode #184288528: lblock 2: comm rg: error -5 reading directory block
[5789751.027987] EXT4-fs warning (device md127): htree_dirblock_to_tree:994: inode #161822641: lblock 7: comm cp: error -5 reading directory block
[5789751.027989] EXT4-fs warning (device md127): htree_dirblock_to_tree:994: inode #184288528: lblock 2: comm rg: error -5 reading directory block

Reading up on this, I found several articles on fixing this by doing fsck (I'm using Ubuntu 18.04).

I also found someone having the same issue with them using RAID0 disk (but a very long time ago since it's kernel 4.0.0).

My disk seems healthy since the output of smartctl reads PASSED. And inode seems to be functioning since there is still a lot left (only used 7% of inodes).

What could be the cause of this spontaneous failure? I would like to know since I want to know how I could prevent it or be ready for it next time it happens.

Currently, I'm still copying over non-corrupted files, but I'm planning to fix it by fsck.

haruishi
  • 21
  • This is a hardware error that may be corrected by running fsck. Go on backing up as much as possible, and then run fsck. – Jos Jan 05 '21 at 13:14
  • Yeah, everyone who had these types of errors uses fsck and magically this issue goes away. I was just wondering what is the cause of it and how I could prevent it in the future so that I wouldn't have to go through this hell again... lost so many important files so – haruishi Jan 05 '21 at 13:49
  • There is some redundancy built into a hard drive. That means that you can use a program like fsck to retrieve data from "bad blocks", i.e. areas on the drive that are physically damaged. Moreover, the fsck program will move the rescued data elsewhere, and keep a list of blocks that are found to be "bad" and are not to be used again. – Jos Jan 05 '21 at 16:50
  • ah I see, I didn't know you could also do that with fsck. Thanks for the help! – haruishi Jan 06 '21 at 00:12

0 Answers0