Ubuntu Systemd Bad Entry
-
Yes, you want to fix the bad inodes.
-
Fix in progress
-
md status degraded? SMART status? Could also be a dying spindle.
Filesystem remounted ro (should be in case something goes south)? -
If this hardware is bad (its just a shit desktop I'm using for this purpose) I'm making the boss purchase equipment.
-
Clear the blacklist entry?
-
@DustinB3403 said in Ubuntu Systemd Bad Entry:
If this hardware is bad (its just a shit desktop I'm using for this purpose) I'm making the boss purchase equipment.
Oh, this isn't a server? Very good chance that this is a hardware failure causing the corruption.
-
Can be a URE as well. Without RAID, URE comes up and this is often what it would look like.
-
@DustinB3403 Yes, clear.
-
MD RAID 10 is configured on this box for the storage space. So I can check that as well.
-
@DustinB3403 said in Ubuntu Systemd Bad Entry:
MD RAID 10 is configured on this box for the storage space. So I can check that as well.
Should be the very first thing to check.
-
lots of deleted/unused inodes, clearing them all.
-
@DustinB3403 said in Ubuntu Systemd Bad Entry:
lots of deleted/unused inodes, clearing them all.
That is common in scenarios where you have filesystem corruption.
-
Inode ____ ref count is _, should be . Fix<u>?Correcting these issues.
-
@thwr said in Ubuntu Systemd Bad Entry:
@DustinB3403 said in Ubuntu Systemd Bad Entry:
MD RAID 10 is configured on this box for the storage space. So I can check that as well.
Should be the very first thing to check.
Array status:
mdadm --detail /dev/mdxhttps://raid.wiki.kernel.org/index.php/Detecting,_querying_and_testing#Querying_the_array_status
-
it looks like xvda is having issues according the current screen.
Might have to replace that drive...
-
At the moment the system appears to just be progressing through the blk_update_request with I/O errors for individual sectors on XVDA.
Should I abort this operation and find a replacement drive? Is it worth it to let this continue?
-
@DustinB3403 said in Ubuntu Systemd Bad Entry:
At the moment the system appears to just be progressing through the blk_update_request with I/O errors for individual sectors on XVDA.
Should I abort this operation and find a replacement drive? Is it worth it to let this continue?
Hard to say. Real data on it? Would try to get a last backup first before doing filesystem operations.
-
Yeah, all comes down to the value of recovery, really.
-
I don't mind tearing down the system, it's only running 1 VM that I'm backing up my VM's too. Which those delta's get pushed off nightly to another disk.
-
Time to reboot
