Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
The intent of fsck to check a filesystem. What exactly it does is dependent on the filesystem type and on the extent if any of damage.
For example for non-journaled filesystems it typically has to read all the blocks and verify everything including superblocks are where they are. For a journaled filesystem on the other hand it typically just tries to verify that what was last logged in the journal has been committed to the data and if not does the commit. However a "full" fsck on a journaled filesystem does pretty much what it did on non-journaled. On Linux by default this full fsck is done on ext3 which is a journaled version of ext2 (which wasn't journaled) after a certain number of mounts or number of days.
VxFS which is Veritas' journaled filesystem is something that I only did a full fsck on when I suspected or saw filesystem issues. Others have suggested that although you could disable the automatic full of ext3 on Linux it isn't a good idea unless you're scheduling a time to do it yourself.
The main thing fsck does is to fix issues found in order to make the filesystem perform better and/or to repair damage so that an unmountable filesystem again becomes mountable.
To get into more detail you'd really need to investigate the filesystem type you're interested in and then find what fsck does for that specific filesystem.
fsck didn't convert your filesystem to write mode. It fixed the issue that made your system decided to mount in read only.
That is to say at boot the system tries to mount filesystems but if it finds issues it will mount as read only to prevent further corruption then tell you to run an fsck to fix whatever it issues existed. It doesn't automatically do the fsck because there is a potential the fsck would render the filesystem completely unusable. By mounting read only it gives you a chance to try to save important information before you attempt the fsck.
Again unless you want to study the underlying filesystem structures in detail the best answer is "it tries to fix the filesystem". In most cases it DOES. Some user prefer to interact with fsck answering questions as it goes along but many people just run "fsck -y" as they don't understand the underlying structures and don't want to answer the potentially hundreds of questions it asks.