[ale] fsck opinions

[Michael Trausch]

Upgrade to ext4 and then fsck. First fsck will take a long time. Future
fscks will not, as they do not need to check every single inode---only the
inodes that are used.

Never, ever disable fsck. Journalling does not eliminate the need for fsck,
it just makes it possible to optimize the process for the common scenarios
such as power loss. Filesystems can still lose integrity for other reasons,
though.

--
Sent from my phone... a G2 running CM7 nightlies!
On Feb 24, 2011 10:12 AM, "Lightner, Jeff" <jlightner at water.com> wrote:
> Since ext3 is a journaled filesystem is there any reason to continue
> doing automatic fscks of filesystems on boot? If so why?
>
>
>
> RHEL by default does fsck if rebooted if one hasn't been done in some
> number of days (this is configurable). However, if it does this on a
> system with lots of large filesystems it can take hours to boot. This
> causes complaints in the event of an unexpected server boot because we
> let it run.
>
>
>
> Last night I saw an issue with "sleeping on disk" on a process so of
> course it can't be killed and the filesystems can't be unmounted. I
> think (but am not sure) that this is the only server where we disabled
> the fsck. I'm going to check into that but before I push back on
> whether fsck is needed I'm just wondering what others think.
>
>
>
> My co-worker says he was told in training he took that it isn't
> necessary. Long ago I was told similar information for the Veritas
> (VxFS) journaled filesystem used for HP-UX and Solaris
>
>
>
> ________________________________________________________________________
> __________________
>
> Jeff Lightner | UNIX/Linux Administrator | DS Waters of America, Inc |
> 5660 New Northside Drive, Ste 250 | Atlanta, GA 30328
> *: (Direct Dial) 678-486-3516 |*: (Cell) 678-772-0018 |
> *:jlightner at water.com
>
> Proud partner. Susan G. Komen for the Cure.
>
> Please consider our environment before printing this e-mail or
attachments.
> ----------------------------------
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
information and is for the sole use of the intended recipient(s). If you are
not the intended recipient, any disclosure, copying, distribution, or use of
the contents of this information is prohibited and may be unlawful. If you
have received this electronic transmission in error, please reply
immediately to the sender that you have received the message in error, and
delete it. Thank you.
> ----------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20110224/1f944ffd/attachment.html