Why is the filesystem state of _mounted_ ext filesystems clean?

Asked by AmenophisIII on 2011-02-06

until today i thought that any ext fs will get its "dirty" bit set when it is mounted. but it seems that this is not the case?
tune2fs and dumpe2fs both report... e.g.
tune2fs -l /dev/mapper/ssd-root
tune2fs 1.41.12 (17-May-2010)
...
Filesystem state: clean
...
for all my mounted ext4 partitions on maverick.
grep ssd-root /proc/mounts
/dev/mapper/ssd-root / ext4 rw,noatime,errors=remount-ro,barrier=1,data=ordered 0 0

I also tested this on an older debian box with ext3. I want to be sure a filesystem is clean before i snapshot it with lvm for backups. i thought greping the output of tune2fs would be the best and fastest way...

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu e2fsprogs Edit question
Assignee:
No assignee Edit question
Solved by:
Eliah Kagan
Solved:
2011-02-06
Last query:
2011-02-06
Last reply:
2011-02-06

http://manpages.ubuntu.com/manpages/maverick/en/man8/tune2fs.8.html (man 8 tune2fs) says:
"If you are using journaling on your filesystem, your filesystem will *never* be marked dirty...."

AmenophisIII (amenophisiii) said : #2

damn, i even wrote "dirty" in my question, but did not look for it in the manpage... only searched for "clean". sorry!

i'll solve the problem with fsck.ext4 -n and looking at the return code then. takes a few seconds tough... any other suggestions?
thanks

AmenophisIII (amenophisiii) said : #3

Thanks Eliah Kagan, that solved my question.

"any other suggestions?"

Do you just want to find out if the filesystem is (mounted OR dirty) ?

AmenophisIII (amenophisiii) said : #5

dirty.
i am making a snapshot with an initramfs boot script and will then sometime later (via upstart or cron) backup from that snapshot. and i don't want to make backups from a possibly faulty fs.

If you want to ensure to a reasonable degree of certainty that the filesystem you're backing up is OK, it sounds like you might want to scan the filesystem for errors even if it were non-journaled (i.e. capable of being marked dirty) and in the clean state. Not all bad things that can happen to a filesystem will result in its being marked dirty, even when it is otherwise eligible.

In the sentence just before the one I excerpted above, tune2fs(8) says: "Bad disk drives, cables, memory, and kernel bugs could all corrupt a filesystem without marking the filesystem dirty or in error."

AmenophisIII (amenophisiii) said : #7

that's true and i am fully aware of that. it does not make sense though to check it on every boot (default checktime seems to be 6 months on my system). i just wanted to make sure it is not apparently broken.