https://bugzilla.kernel.org/show_bug.cgi?id=114821 --- Comment #6 from Lukas <dse.ssd@xxxxxxxxx> --- I agree, the head cycling does seem unlikely to be caused by software. But I'm confused how can the drive be 'failing' simple reads so often and yet pass every fitness, including a vendor diagnostic test of every sector... I cannot create a drive image... It is 4TB in size and I don't have that much contiguous free storage at my disposal. What I could do is wipe the drive and re-create the ext4 partition. I have most of the contents backed up. It sounds like a radical way of testing, but let me know if that's my only option. In the mean time I've done some more testing. Maybe it will prove useful. Firstly, I've reproduced the error on Raspbian 8 with 4.1.18-v7+ kernel running on a different Raspberry Pi device. (Sorry, the kernel is again non-vanilla). Upon accessing a particular file on the drive, I can hear the head load cycle and a dmesg ext4 error is logged. Secondly, I've noticed that most of the ext4 errors are due to smbd and for the same inode #1523. That inode seems to be accessed quite often whenever I do anything with the drive. I ran $ debugfs -R "ncheck 1523" /dev/sdb1 and determined that the inode holds a single text file in the root directory of the drive - 'file.txt'. I cannot list or delete this file: % ls -li ls: cannot access file.txt: Input/output error ? -????????? ? ? ? ? ? file.txt $ rm file.txt rm: cannot remove `file.txt': Input/output error If I execute $ debugfs -R 'cat <1523>' /dev/sdb1 it returns nothing and I believe the file should be empty. The command takes a few minutes to execute, which I don't think is normal too. I know this sounds even more like hardware problems, but, again, there's nothing in the SMART attributes, self-tests or vendor diagnostic tests to support that. Should I attempt to delete this file using debugfs? Or should I re-create the partition from scratch? Or should I just get another drive, close this 'bug' and stop troubleshooting? -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
