Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then 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.
Conventional wisdom is that file systems need periodic fscking but is it always the best approach?
Ubuntu think not. On a default installation they disable boot time fsck on at least ext* file systems. Bug https://bugs.launchpad.net/ubuntu/+s...s/+bug/1083985 refers. From that bug page: "This was an intentional change in e2fsprogs. The periodic check is pretty pointless and annoying so it was disabled by default".
Maybe Ubuntu's decision came from prioritising user convenience over data integrity. Maybe their target users wouldn't know what to do if fsck generated a prompt for interaction. Maybe it's a good choice in Ubuntu's situation.
Theodore T'so, the ext4 developer, consistently says fscking is necessary and he should know. Sorry -- can't find any links now.
When block devices are provided by iSCSI they cannot be fscked at boot when processing fstab because they don't exist; they are not created until the iSCSI client/initiator service is running. There are a lot of pages on the 'net about this issue but none of the pages I found mention a way of periodically fscking such devices; the usual solution is simply to use option _netdev to defer mounting.
That suggests there are many file systems on iSCSI devices which are not periodically fscked. They are unlikely to be used with personal computers; iSCSI is mostly used with servers. So data integrity is more important and systems administration skills are more available.
Maybe do a fsck on the machine providing the iSCSI target. Something like: we have an unmount okay lets clean it up. Whos turn is it. fsck's.
Honestly I never had any thoughts about fscking my filesystems and let the system handle it. With journals beeing around for quite some time now fsck at start up is realy fast as it does not need to check on all the files but only those in the journal. As for manually doing fsck I seldomly do. I somewhat must say for me this is forgotten lore so you might be right with the world moving away from periodic fsck. I guess mostly due to high uptime needs or no scheduled mantainance intervals.
I can't comment on corporate and enterprise setups, but for my personal computer, I don't see it as vital. Good backups of one's data is far more important. Modern file systems are designed to be 'self-healing' as far as I know and all of the data recovery I've done for friends and relatives revolve around fat32 formatted flash memory cards. (usually for cellphones, which don't do any filesystem checks.)
My experience accord with qlue's. I've only run fsck when I've had a problem, and that's been very rare.
I notice, though, that many distros are set by default to fsck the root partition after X number of reboots (X usually seems to equal 27 or 28). That is controlled by the sixth field in /etc/fstab.
Here's an excerpt from man fstab:
The sixth field (fs_passno).
This field is used by the fsck(8) program to determine the order in which
filesystem checks are done at reboot time. The root filesystem should be
specified with a fs_passno of 1, and other filesystems should have a fs_passno
of 2. Filesystems within a drive will be checked sequentially, but filesys‐
tems on different drives will be checked at the same time to utilize parallel‐
ism available in the hardware. If the sixth field is not present or zero, a
value of zero is returned and fsck will assume that the filesystem does not
need to be checked.
Modern file systems are designed to be 'self-healing'
This "self healing" is done via fsck during boot. Seriously, with a somewhat modern filesystem (for example ext4 or jfs) fsck during boot usually is less than 5 seconds even on very large drives. So if you do it as recommended (usually every 25-35 mounts or 180 days) it doesn't harm anyone and you are on the safe side.
Journaling file systems can heal themselves when they are mounted by checking out the entries in the journal. This is far faster than fscking the entire file system and may make fsck redundant for journaling file systems like ext3 and ext4. Ubuntu's disabling of fsck checks at boot is probably a reasonable thing to do.
Is it *necessary*? In a world where hardware is perfect, no. In a
world where people don't bother buying ECC memory because it's 10%
more expensive, and PC builders use the cheapest possible parts --- I
think it's a really good idea.
From the tune2fs man page (e2fsprogs-1.42.6 version):
You should strongly consider the consequences of disabling mount-count-dependent checking entirely. Bad disk drives, cables, memory, and kernel bugs could all corrupt a filesystem without marking the filesystem dirty or in error. If you are using journaling on your filesystem, your filesystem will never be marked dirty, so it will not normally be checked. A filesystem error detected by the kernel will still force an fsck on the next reboot, but it may already be too late to prevent data loss at that point