I have a pretty basic system running Ubuntu 16.04 (this question is not specific to Ubuntu, but rather ext4
partitions), 1 HDD, running a few partitions:
sda1 - EXT4 - 100G - / sda2 - EXT4 - 723.5G - /home sda3 - NTFS - 100G - (windows) sda5 - SWAP - 8G
Whenever I try to access one of 3-4 files in a specific directory in the /home
partition, (the specific folder causing the issues is /home/path/to/broken/folder
), the /home
partition will error and remount read-only. dmesg
shows the following errors:
EXT4-fs error (device sda2): ext4_ext_check_inode:497: inode #1415: comm rm: pblk 0 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) Aborting journal on device sda2-8. EXT4-fs (sda2): Remounting filesystem read-only EXT4-fs error (device sda2): ext4_ext_check_inode:497: inode #1417: comm rm: pblk 0 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) EXT4-fs error (device sda2): ext4_ext_check_inode:497: inode #1416: comm rm: pblk 0 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
So I understand what is going on...some bad block is causing an error and is remounting the drive read-only to prevent further corruption. I know it is these specific files because I can undo the error by
- Logging in as root
- Running
sync
- Stopping
lightdm
(and all sub-processes) - Stop all remaining open files on
/home
by finding them withlsof | grep /home
- Unmounting
/home
- Running
fsck /home
(fixing the errors) - Remount
/home
Everything is fine again, read and write, until I try to access the same files again, then this entire process is repeated to fix it again.
The way I've tried to access the files is by running ls /home/path/to/broken/folder
and rm -r /home/path/to/broken/folder
, so it seems any kind of HDD operation on that part of the drive errors it and throws it into read-only again.
I honestly don't care about the files, I just want them gone. I am willing to remove the entire /home/path/to/broken/folder
folder, but every time I try this, it fails and throws into read-only.
I ran badblocks -v /dev/sda2
on my hard drive, but it came out clean, no bad blocks. Any help would still be greatly appreciated.
Still looking for a solution to this. Some information that might be useful below:
$ debugfs -R 'stat <1415>' /dev/sda2 debugfs 1.42.13 (17-May-2015) Inode: 1415 Type: regular Mode: 0644 Flags: 0x80000 Generation: 0 Version: 0x00000000 User: 0 Group: 0 Size: 0 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 0 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x5639ad86 -- Wed Nov 4 01:02:30 2015 atime: 0x5639ad86 -- Wed Nov 4 01:02:30 2015 mtime: 0x5639ad86 -- Wed Nov 4 01:02:30 2015 Size of extra inode fields: 0 EXTENTS:
Now I looked at this myself and compared it to what I suspect to be a non-corrupted inode:
$ debugfs -R 'stat <1410>' /dev/sda2 debugfs 1.42.13 (17-May-2015) Inode: 1410 Type: regular Mode: 0644 Flags: 0x80000 Generation: 0 Version: 0x00000000 User: 0 Group: 0 Size: 996 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 0 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x5639ad31 -- Wed Nov 4 01:01:05 2015 atime: 0x5639ad31 -- Wed Nov 4 01:01:05 2015 mtime: 0x5639ad31 -- Wed Nov 4 01:01:05 2015 Size of extra inode fields: 0 EXTENTS: (0):46679378
I have bolded what I believe are the key differences here. I looked at other non-corrupted inodes and they display something similar to the 1410
that has a non-zero size and an extent.
Bad header/extent makes sense here...it has no extent....how do I fix this without reformatting my entire /home
partition?
I really feel like I've handed this question to someone smarter than me on a silver platter, I just don't know what the meal (answer) is!
e2fsck -pf /dev/sda2
while unmounted?