I have 2TB ext4 partition with half million files on it.
I want to check whether this partition contains any errors or not.
I don't want to search for bad blocks, only logical structure should be checked.

I have unmounted the partition and run fsck /dev/sda2, but fsck returns immediately with exit code 0 without actually checking whole file system.
I'm expecting full partition check would take hours to complete.
I have read man fsck but did not find an option for "thorough testing".

I'm afraid my partition may have some sectors accidentally overwritten by garbage data.
My HDD was previously connected to another OS, and ext4 partition may get harmed by wrong behavior of that OS.
That's why I want to be sure the whole tree structure is completely correct.

In other words, I want to perform a check similar to what utility chkdsk.exe does on Windows.
What should I use on Debian to completely check ext4 file system?

  • 2
    @SatoKatsura - Thanks! I just wonder why e2fsck -f check is so fast - it takes only several seconds? It's amazing compared to Windows behavior (it takes hours). Feb 24, 2017 at 10:30

5 Answers 5


As mentioned by Satō Katsura, run e2fsck in "force" mode:

e2fsck -f /dev/sda2

This will force a check even if the system thinks the file system is clean. The "verbose" option is helpful too:

e2fsck -vf /dev/sda2

As a side-note, and not applicable in your case, but if you use LVM for your storage you can use the neat little lvcheck tool to run an "offline" file system check on a mounted file system (it uses an LVM snapshot and updates the file system metadata if the check doesn't find any errors).


Also, you could add the -y flag to avoid answering questions.

From the manual:

-y assume an answer of yes to all questions; allows e2fsck to be used non-interactively.

So extending the answer (since I cannot comment yet) from @Sato - you could run:

e2fsck -vfy /dev/sda2
  • 9
    That can be risky though, because you don't know in advance what you may get asked, and forcing a yes answer to everything could in the worst case lead to loss of otherwise recoverable data.
    – Alex
    Feb 24, 2017 at 13:10
  • @Alex, Interesting! Could you give an example of a situation where -y can cause "loss of otherwise recoverable data"? Jan 16 at 18:06
  • 1
    @PetaspeedBeaver Nothing concrete, no. But I've had a borked filesystem in the past where my internet searches led me to reading forum posts where I found examples of people running fsck (or similar) who let it do fixes actually caused more corruption. Anything tool that "automatically fixes" something can, under the right circumstances, fix things incorrectly if the (meta)data corruption is bad enough.
    – Alex
    Jan 26 at 12:24

During boot a linux system will check the fstab or the existence of a file named forcefsck in the root of the device. if the last number on the mount line in fstab is 0 the device will be checked during boot. To create the file forcefsck use these commands.

sudo touch /forcefsck
sudo reboot

With this file at the root a volume the same will be checked during (re)boot irrespective of what is in fstab.

The downside is that during fsck the system is unavailable and will not respond to remote requests over for instance ssh.

(EDIT according to @kusalananda comments)

  • 6
    Although possibly correct, this answer lacks any form of explanation. Could you possibly describe what your commands do, what the consequence of them would be, and where the user in the question might read more about this (where there might have learnt this if they had found the correct manual, etc.)?
    – Kusalananda
    Apr 18, 2020 at 6:42
  • 1
    This answer is as close to self-explanatory as two commands could be. 99.9% of the time I would appreciate more explanation, but this time, it's clear enough not to need it. Rare, but it happens. Aug 22, 2021 at 14:39
  • 1
    Really? Doesn't seem clear to me. I'm guessing that on reboot, if the directory forcefsck exists on root, a check desk will be run. Not sure. Now to google it and confirm, and provide a reference.
    – codenoob
    Jun 25, 2022 at 17:31
  • Ok, so obviously, it's a file that is created, not a directory (there's now 'mkdir'). And indeed, it would seem to work: linuxconfig.org/…
    – codenoob
    Jun 25, 2022 at 17:33
  • This would work but also halt booting until the check is finished. For a 2TB disk this might take the system off-line for a long time.
    – theking2
    Jun 29, 2022 at 7:39

You can also check live file systems in read-only mode with this:

e2fsck -vfn /dev/sda2
  • 2
    From e2fsck help: "However, even if it is safe to do so, the results printed by e2fsck are not valid if the filesystem is mounted." Not sure what the purpose is of such as check... :/
    – joaerl
    Aug 20, 2019 at 11:16

You could also use tune2fs for this purpose, for example the following command will check the disk after 2 months or 100 mounts:

tune2fs -c 100 -i 2m /dev/sda1
  • Not on android. Dec 19, 2023 at 14:13
  • @user2284570 question was about debian, not android ;-)
    – m13r
    Dec 19, 2023 at 22:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .