Hi all,

I am running a server with an ext3 filesystem as root partition and I really don't like to boot the machine with any rescue cd's everytime that e2fsck finds someting to fix.
On the other hand, I cannot find any information about how safe it is to do e2fsck on a read only mounted file system.

Does anyone know anything about this? Or can point me somewhere fpr further reading!

Thanks a lot!!!
Clemente

You shouldn't be running fsck on a mounted filesystem, whether it's ro or not. The kernel should check all file systems periodically on boot, before the partitions are mounted. If file system corruption is occurring regularly, you have a problem, which should be fixed as soon as possible!

Hi Gethyn,

no good news... But thanks anyway
To summarize: If I use any ext3 filesystem on a sevrer, I have to periodically reboot the machine. No safe way out.

What could I do, if I want to establish a 24/7 server. I cannot reboot periodically in this szenario.

Thanks for any (even bad ) news,
Clemens

Unless you have hardware problems, there shouldn't be any filesystem corruption occurring in a system that's always on. The usual cause of filesystem corruption is improper shutdown of a machine.

My advice would be to (a) invest in an uninterruptible power supply, so if there is a power cut you can shut the machine down properly, and (b) make regular backups. If this is for a production server, you should already have these measures in place.

Gethyn, I've run fsck on read only mounted file systems on numerous occasions without incident. In fact, given that the e2fsck program itself lives on the root filesystem, the kernel pretty much has to mount it read only to run fsck (unless it's on some sort of RAM disk or network mountable filesystem that the kernel can get access to early in the boot process, which is usually not the case as usually automatic fscks are handled by init after / has been mounted ro).

That being said, you must never ever run fsck on a writeable filesystem. That would be bad.

If the OP is seeing constant file corruption, that generally means bad RAM (corrupting disk buffers and such) or (more likely) a hard drive on the way out, assuming that the power is reasonable stable. The advice about having back-ups is spot on -- they've saved my rear on many an occasion.