I know that before running the kernel, u-boot (the boot loader) will check the kernel image CRC. Only if it is correct it will go further, else it will give a "Bad CRC" error.

I want to do same thing for file system too.

  1. Is there any way to do that?

  2. Does the kernel check whether file system is proper or not before loading it? If yes, where is this check done?


I am using jffs2 file system. Is it possible to check CRC of this type of file system? Or any other way to make sure that the jffs2 file system is not corrupted ?

  • 1
    The CRC notion is sound only for files that does not have to change, like a kernel file. A file within a filesistem is mean to be modifiable (save permissions). But modern filesistems (like ext3/4 and others) have auto-checks (and some recovery) at start time, to assure the whole filesistem is 'sane'. I'm not sure to understand you question, could you please elaborate ? – DavAlPi May 20 '13 at 14:07
  • 3
    Actually @DavAlPi several high-end file systems (ZFS being one) store and validate even data (payload) checksums, and can be configured to use the result of those checksum checks to aid error detection and recovery. So the answer to this would depend on the file system in use. (And there is nothing magical about the kernel image, except the consequences of corruption can potentially be disasterous.) – a CVn May 20 '13 at 14:10
  • 1
    @MichaelKjorling No offense intended, but I don't think you actually correct DavAlPi there. You did add ZFS to the list, but DavAlPi's main point was that the filesystems currently popular on GNU/Linux have consistency checks. I also don't know that CRC's of metadata are all that high end, especially since ext4 does user data and metadata and I wouldn't call that high end as well. ZFS was ahead of its time but is currently on par with most other filesystems that are even remotely well designed. – Bratchley May 20 '13 at 16:55
  • I should clarify that last statement: ZFS is still a little bit more advanced than the filesystems most popular on GNU/Linux when it comes to having a volume managing filesystem, but a lot of the features can be achieved with LVM+ext4 or are coming down the pipeline with BTRFS (like balancing/scrubing, subvolume quotas, plus the stuff ext4 has, and some of the volume management functionality of LVM). BTRFS is also only going to grow in the future and inspire spinoffs. – Bratchley May 20 '13 at 17:00
  • 2
    @androidbuddy jffs2 does checksums as well: "Every type of node starts with a common header containing the full node length, node type and a cyclic redundancy checksum (CRC)" jffs2 also does a filesystem check every time you mount it, so you should be good. more info – Bratchley May 23 '13 at 19:54

(links below are supporting documentation and not necessarily directly related to your question).

As Michael and DavAlPi pointed out some filesystems (like ext4, btrfs and zfs) CRC both files and filesystem metadata.

With ext2, the filesystem is modified with each mount, setting it to "dirty."(this was replaced with needs_recovery in ext3) When it is unmounted this is unset. If system initialization sees an unmounted filesystem marked as dirty, it will assume it was unmounted uncleanly and run a filesystem check to ensure integrity. On RHEL this is usually done somewhere around the "remounting root" message during startup. Either way, it's going to be one of the first things the distro does.

With ext3 you get a journal, so if the filesystem is corrupt due to unexpected failures, it will either "replay" journal transactions or ignore them, whichever is most likely to not cause problems. You don't get CRC's though so if the data is just plain dying (failing HDD platter for instance), it's just how it's going to be. But ext3 can be upgraded to ext4 if you need the features and it shouldn't create any userland issues.

So one way or another, filesystem integrity is checked, but using the latest filesystems gives you some additional protections.

  • I haven't seen anything about CRC checksums for files (content, not metadata) stored on an ext4 filesystem in that link. – Cristian Ciupitu Jul 4 '14 at 8:45
  • Which link? There's three and it's been over a year since I wrote that. – Bratchley Jul 4 '14 at 14:35
  • The one for ext4 of course :-) – Cristian Ciupitu Jul 4 '14 at 16:17
  • It's possible that I read the part about inodes being CRC'd and assumed it included the data it was pointed to. Reading more it doesn't look like that's the case. Filesystems aren't my area of expertise so this is probably just a question I thought was interested and went off to research the answer myself. Like I said, it's been a while since I posted this though. – Bratchley Jul 4 '14 at 17:37

Generally all modern file system drivers contain some sort of checks that ensure the file system being mounted is in coherent state - usually in the syntactical sense, not the semantical one, so you may still end up with garbage (but it will be a well structured garbage).

As for JFFS2 check sections 3.1 and 3.5 of the documentation - some checks are done.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.