[ale] fsck opinions
Lightner, Jeff
jlightner at water.com
Thu Feb 24 10:11:44 EST 2011
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/0e4941f7/attachment.html
More information about the Ale
mailing list