Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
More of a linux filesystem question
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
LIsLinuxIsSogood
Veteran
Veteran


Joined: 13 Feb 2016
Posts: 1090

PostPosted: Wed Nov 27, 2019 11:57 pm    Post subject: More of a linux filesystem question Reply with quote

I was wondering for a single "corrupt file" in the filesystem (that appears to be unrelated to any larger problems...and was possibly/probably just the result of a little bit too much experimenting (with hibernating, reading, writing, to the system). Now I can't actually see any harm in doing it either one of these two ways, so want to ask for some help...
1) Just leaving a single corrupt file in place and hoping (because I don't know the ramifications of having a single corrupt thing on the disk)
OR
2) Going the extra mile to ensure this isn't hardware failing or anything serious like that by doing my complete backup, and reinstalling...this seems so overboard to me given the lightness of the situation.

But also is it possible just to unmount the drive and try to fix this with another tool, like fsck? Will that help maybe to remove a corrupt or whatever file?
Back to top
View user's profile Send private message
TheLexx
Tux's lil' helper
Tux's lil' helper


Joined: 04 Dec 2005
Posts: 135
Location: Austin Tx

PostPosted: Thu Nov 28, 2019 12:48 am    Post subject: Reply with quote

I'm not exactly sure what you are asking. There are a few questions that may change the out come.

Q1. When you say "corrupt file", do you mean that it is just the file that is corrupt, or do you mean that, there is a corruption in the filesystem linked to that file. In other words, if it is just the file that is corrupt and NOT the filesystem that is corrupt, then reading the file will NOT cause a error to appear in dmesg. If your file is foo.jpg and your image viewer says "can't display foo.jpg file corrupt". Then you are most likely talking about a single corrupt file, and not a corrupt filesystem. If reading the file cause something like "error reading file" to appear in the dmesg log then you are talking about a corrupt filesystem linked to a particular file. For the rest of the questions I am assuming something that causes errors in the dmesg.

Q2. What filesystem type (ie. ext3, ext4, vfat, xfs ...) in the corruption on? This could make a bigger deal. Some filesystems are more prone to spreading corruption than others.

Q3. Is the corrupt file on a partition that can be unmounted while the Gentoo system is running. The default Linux system is to place most of the system on the same partition. Even when you go "old school" (like me) and have separate partitions, there are many partitions that can't be unmounted while running. There are many partitions that I wouldn't suggest unmounting while running, /usr comes to mind. It might be possible to remove /var and/or /tmp, but I'm not that brave. If /home is a separate partition you can unmount that as long as only root is logged in. However even after "normal users" log off there are sometimes desktop activated programs that run in the background, these may have to be killed manually before unmounting /home.

Generally speaking, I try to run fsck an soon as convenient when I encounter a filesystem anomaly that causes something to appear in dmesg. Simply removing such a file will not always correct the issue. With ext3 and ext4 corruption generally does not spread (unless the drive itself is failing). Speaking of failing drives the utility smartctl is a good way of diagnosing that.
Back to top
View user's profile Send private message
LIsLinuxIsSogood
Veteran
Veteran


Joined: 13 Feb 2016
Posts: 1090

PostPosted: Thu Nov 28, 2019 1:15 am    Post subject: Reply with quote

Good advice, thanks. The problem has been resolved when I noticed that the specific non-gentoo distro I was using had a local rescue image installed, which dropped me into a root mode and luckily (or be design) performed some fsck automatically before that and fixed the corruption. Instead of seeing a single unknown file with no known properties it now displayed the host of several files in a folder (a package manager related group of files) and I was able to resync my package manager as a result.

To answer some of the questions you posed, it was an ext4 filesystem on a luks encrypted partition. And while I only use separate partitions for data here, therefore it was a corruption of the root filesystem (lucky to be resolved I guess). For the time being I will prioritizing getting a full backup done and test it by recovering it too an empty partition on that drive.

Thanks for your help!
Back to top
View user's profile Send private message
TheLexx
Tux's lil' helper
Tux's lil' helper


Joined: 04 Dec 2005
Posts: 135
Location: Austin Tx

PostPosted: Thu Nov 28, 2019 4:02 am    Post subject: Reply with quote

LIsLinuxIsSogood wrote:
Good advice, thanks. The problem has been resolved when I noticed that the specific non-gentoo distro I was using had a local rescue image installed, which dropped me into a root mode and luckily (or be design) performed some fsck automatically before that and fixed the corruption.


It looks like the problem fixed itself, to some degree. If the corruption is on the root directory, you can not fix it by booting up from that partition and running fsck. You must boot from a different partition/drive/dvd/usb-stick. I keep Finnix on a different partition so that I have an alternate booting method close at hand. In the event of corruption in the root directory I do suggest running fsck PDQ, even If you have to halt working on other projects. Although it looks like fsck was already done.


LIsLinuxIsSogood wrote:
Instead of seeing a single unknown file with no known properties it now displayed the host of several files in a folder (a package manager related group of files) and I was able to resync my package manager as a result.


It has been a while (maybe all the way back to when I used ext2)(and I am probably not using the correct terminology), but I do recall that sometimes the directory part can get corrupted and fsck knows that there are files, but it looses which directory the files were in and what the files were named. In those cases it groups the unknown files in a lost+found directory. Once the files are moved out of there origial location the OS usualy looses track of them. It is up to you to figure out if you need them or not.


LIsLinuxIsSogood wrote:
To answer some of the questions you posed, it was an ext4 filesystem on a luks encrypted partition. And while I only use separate partitions for data here, therefore it was a corruption of the root filesystem (lucky to be resolved I guess). For the time being I will prioritizing getting a full backup done and test it by recovering it too an empty partition on that drive.


Experience has told me that backing up is usually the best course of action. Also I would suggest using smartctl, just to be sure the drive is not about to fail on you. If it is then partition to partition backup is of little help. You can use smartctl on the main hard drive that holds the OS that contains the program smartctl. In that since, it is easier to use than fsck. I usually run "--test=short" first to do a quick test. If I still have suspicions I run "--test=long". According to the docs the test will run ok even when there is a lot of data flow in and out of the HD. I might be somewhat superstitious, because I tend to only run "--test=long" when I am away from the computer and there is only minimum data transfer/system load.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum