Hi All,
Below issue is happend rare case on Linux OS reboot .
after reboot the Linux OS , then Ffile systems are corrupted (issue).
1) any command for caputure file systems mount point report -( OS restart before )
2) how to verify file systems health check ( after restart OS ) . Kindly share
Since <quote> the file system was corrupted upon reboot </unquote>, my wild but educated guess (coz of lack of technical details) is that
1) your mounted file system did not get unmounted gracefully upon shutdown
1.1) a bad software or utility has messed up the FAT at MBR or equivalent.
1.2) Your system was too busy and I/O itensive but not optimized for such environment.
2) your restart procedure could not or did not check (and repair) the file system with inconsistencies before mouting it though found corrupted
3) your system has got a deeper hardware error such as bad blocks on the HDD or more weird hardware ones (such as hdd controller or bad memory)
4) last but not least, a bug in the kernel's FS Module.
And here we go the answers to your questions:
1) any command for caputure file systems mount point report -( OS restart before )
> df -hT, mount, dmesg, lsblk -f
2) how to verify file systems health check ( after restart OS ) . Kindly share
> fsck, xfs_repair
But I really wonder what kind of file system are we talking about? ext2/3/4, xfs, etc. etc?
Cheers.
Will
Very glad we could be of help and gladder you found the support helpful.
Additionally, I'd like to point out a couple of things regardig the rare but very critical file system corruption case.
Though any linux compatible modern file systems are quite versatile and resilient, there are trade offs between performance and consistency and they can depending on the situation be found inconsistant or corrupted.
And further more, when you do fsck or xfs_repair, the safest way is to do so on an UNmounted file system. As such, you will sometimes have to deal with rescue or emergency targets aka single user or maintenance mode.. And you might even need to boot from a bootalbe dvd/usb or iso before safely working on or recovering the corrupted file systems.
And then, what if the file systems are beyound repair?
Then, you have no choice but to mkfs.* (aka to format) again provided you have a full back of the file systems.
Have fun with the studies.
Cheers.
Will
Since <quote> the file system was corrupted upon reboot </unquote>, my wild but educated guess (coz of lack of technical details) is that
1) your mounted file system did not get unmounted gracefully upon shutdown
1.1) a bad software or utility has messed up the FAT at MBR or equivalent.
1.2) Your system was too busy and I/O itensive but not optimized for such environment.
2) your restart procedure could not or did not check (and repair) the file system with inconsistencies before mouting it though found corrupted
3) your system has got a deeper hardware error such as bad blocks on the HDD or more weird hardware ones (such as hdd controller or bad memory)
4) last but not least, a bug in the kernel's FS Module.
And here we go the answers to your questions:
1) any command for caputure file systems mount point report -( OS restart before )
> df -hT, mount, dmesg, lsblk -f
2) how to verify file systems health check ( after restart OS ) . Kindly share
> fsck, xfs_repair
But I really wonder what kind of file system are we talking about? ext2/3/4, xfs, etc. etc?
Cheers.
Will
Hi @williamwlk,
Thanks @williamwlk for share your valuable information. Actually above issue is rare but if know the neeceary steps then I can handle that the situation ( if it araise) .
Hi All,
i am getting prompt responses with solutions , compared to raise the case ticket . Actually I am using for RHLS for for personal interest. Finally I am very happy 😊 , learning knowledge from this community. I think it’s best platform for learning. Once again thanks .
Very glad we could be of help and gladder you found the support helpful.
Additionally, I'd like to point out a couple of things regardig the rare but very critical file system corruption case.
Though any linux compatible modern file systems are quite versatile and resilient, there are trade offs between performance and consistency and they can depending on the situation be found inconsistant or corrupted.
And further more, when you do fsck or xfs_repair, the safest way is to do so on an UNmounted file system. As such, you will sometimes have to deal with rescue or emergency targets aka single user or maintenance mode.. And you might even need to boot from a bootalbe dvd/usb or iso before safely working on or recovering the corrupted file systems.
And then, what if the file systems are beyound repair?
Then, you have no choice but to mkfs.* (aka to format) again provided you have a full back of the file systems.
Have fun with the studies.
Cheers.
Will
Red Hat
Learning Community
A collaborative learning environment, enabling open source skill development.