AIX

Well, you can try, but you'll probably have pieces-parts all over...

And it's not just the cache that's the problem with a mounted file system - it's the fact that things are changing. Every file system check I'm aware of assumes the entire file system is static. And it pretty much has to be to ensure consistency. If there's some sort of required consistency between two or more items in the file system, if things are changing there's no way to know if there's an inconsistency because it's corrupt or because it's been changed. The fsck process can't look at the entire file system at one moment in time - it can only look at all the different parts of the file system in some sequence.

I get that I don't want to modify the FS live, however, a really simplistic construction is that the buffer cache contents on top of the disk contents represents the consistent (correct) state of the FS. There is a delay in that consistent state being written through to the disk, i.e. depending on when it's written through. I said "simplistic" and disclaim right away that I don't know the slightest about how that picture changes with journaling.

So again, I don't want to modify it live, but why is it improbably to -check- it live, by looking at the buffer cache, and through to the corresponding on-disk data, and noting (probably with a fair amount of complexity) what inconsistencies -might- be corruption, or which ones are unequivocal signs of it. I anticipate immediately that telling the difference between an inconsistency that's the result of write-through lag, vs. one where no matter how hard the OS tries, the on-disk data can't be made to match what's in the buffer cache because of I/O errors.

Glad to know the conclusion that it's not possible, I'm just curious of the details of why.

But you are modifying it live. It's like trying to read a dictionary while someone else is constantly changing the order of the words -- possibly tearing out pages while they're at it, if they're writing to a corrupt filesystem. If you at least made it read-only, stopped moving things around, it'd be possible to check it.

The kernel makes an awful lot of assumptions about the state of the filesystem. It's the job of it and the journal to keep it that way, but if something else unintentionally alters the filesystem tree -- power outage, disk failure, controller glitch, whatever -- these assumptions may be violated, and using it can cause bad things to happen. Like an index pointing to the wrong disk cluster, causing data to be overwritten or two files to unintentionally share contents, or a file just not mentioned at all anywhere and disappearing from disk, etc, etc.

fsck makes as few assumptions as possible, but does assume the filesystem isn't changing. That's the tradeoff it makes.