Hi,
Is it possible do have fsck to run automatically [without operator intervention], if it was not a clean shutdown.
Right now, somebody has to bring a monitor & keyboard and say Y, if not it will not run and verify the drive. This is for remote headless servers.
Syv Ritch wrote:
Hi,
Is it possible do have fsck to run automatically [without operator intervention], if it was not a clean shutdown.
Right now, somebody has to bring a monitor & keyboard and say Y, if not it will not run and verify the drive. This is for remote headless servers.
Untested: you might try creating the file /etc/sysconfig/autofsck with the content: AUTOFSCK_DEF_CHECK=yes PROMPT=no
On Wed, 2005-11-09 at 16:56, Syv Ritch wrote:
Is it possible do have fsck to run automatically [without operator intervention], if it was not a clean shutdown.
Right now, somebody has to bring a monitor & keyboard and say Y, if not it will not run and verify the drive. This is for remote headless servers.
Do you have some reason to think it is better to run a full fsck than to replay the journal? I thought that was the point of using a journalled filesystem.
Well, I dunno, but I've never had fsck find something missed by the journal, unless the partition is pretty hosed.
-Ben
On Wednesday 09 November 2005 15:06, Les Mikesell wrote:
Do you have some reason to think it is better to run a full fsck than to replay the journal? I thought that was the point of using a journalled filesystem.
It's been a rather long while for me (years) too since I stopped fiddling with experimental kernels/patches and stick with known-stable releases.
Benjamin Smith wrote:
Well, I dunno, but I've never had fsck find something missed by the journal, unless the partition is pretty hosed.
-Ben
On Wednesday 09 November 2005 15:06, Les Mikesell wrote:
Do you have some reason to think it is better to run a full fsck than to replay the journal? I thought that was the point of using a journalled filesystem.
Les Mikesell wrote:
On Wed, 2005-11-09 at 16:56, Syv Ritch wrote:
Is it possible do have fsck to run automatically [without operator intervention], if it was not a clean shutdown.
Right now, somebody has to bring a monitor & keyboard and say Y, if not it will not run and verify the drive. This is for remote headless servers.
Do you have some reason to think it is better to run a full fsck than to replay the journal? I thought that was the point of using a journalled filesystem.
Q: If a system shutdown hard, even with journaling is it at all necessary to run e2fsck?
Theodore Ts'o, the ext2 developer, said:
It's best to just always run e2fsck. [...] E2fsck will run the journal automatically, and if the filesystem is otherwise clean, it skip doing a full filesystem check. If the filesystem is not clean (because during the previous run the kernel noticed some filesystem inconsistencies), e2fsck will automatically do a full check if it is necessary. If you have multiple disks, fsck will run multiple e2fsck processes in parallel, thus speeding up your boot sequence than if you let the kernel replay the journal for each filesystem when it tries to mount it, since then the journal replays will be done sequentially, instead of in parallel.
http://batleth.sapienti-sat.org/projects/FAQs/ext3-faq.html
Les Mikesell lesmikesell@gmail.com wrote:
Do you have some reason to think it is better to run a full fsck than to replay the journal?
Actually, unless you're doing full data journaling (especially with a NVRAM board), it's almost always _safer_ to run a full fsck instead of just doing a journal replay.
I thought that was the point of using a journalled filesystem.
The point of using a meta-data journaling filesystem is to [near] guarantee the filesystem into a consistent state without having to run a time-consuming fsck. Journaling doesn't guarantee anything as far as reliability (and can actually be worse -- don't get me started on NTFS ;-).
Full data journaling filesystems are better (and worse in some ways) than meta-data journaling filesystem. But full data journaling filesystems using a NVRAM for the journal is near-perfect because you have a commit to near-instaneous, battery-backed DRAM -- which is the journal (not disk) -- before any flush to disk.
(Tangent Warning=ON)
Tying in a recent thread, NetApp's Data OnTap OS is designed to buffer to NVRAM as the journal for the WAFL filesystem. That's why it recovers so quickly and near perfectly -- the OS/filesystem is designed around that advanced hardware capability (which all NetApp filers have).
VALinux used to sell filers with a similar (albeit more conventional) option using a PCI NVRAM board, Ext3 in full-data journaling and NFS in sync mode (instead of async). It wasn't any faster than NFS async, but it was much, much safer (basically async for free).
Syv Ritch centos@911networks.com wrote:
Hi, Is it possible do have fsck to run automatically [without operator intervention], if it was not a clean shutdown.
Yes. If you look in /etc/rc.d/rc.sysinit on any Fedora-based distro, you'll note the fsck/mount lines that are run that basically inspects all filesystems before mounting read/write. You'll want to add "-y" in there as appropriate.
I don't recommend this as a standard though.
Right now, somebody has to bring a monitor & keyboard and say Y, if not it will not run and verify the drive.
You could pump console to a serial port. ;-> In fact, I'd highly recommend that instead.
This is for remote headless servers.
Consider using a system solely for remote access (via SSH) with a multi-port serial card so you can access any such systems. In fact, if such servers have Phoenix ServerBIOS (or similar), you can seutp BIOS/CMOS setup access from the serial port as well.
Syv Ritch centos@911networks.com wrote:
Q: If a system shutdown hard, even with journaling is it at all necessary to run e2fsck? Theodore Ts'o, the ext2 developer, said: It's best to just always run e2fsck. [...]
It should also be noted that attempting to mount an Ext3 filesystem will also flush the journal, if it was inconsistent and needs to be flushed.
In the "good'ole days" (circa kernel 2.2 -- yes, Ext3 ran on it ;-), this wasn't always the case with older mount/e2fsprogs versions. ;->
-
Alan Sparks -
Benjamin Smith -
Bryan J. Smith -
Chris Mauritz -
Les Mikesell -
Syv Ritch