Editing Fsck (section)

=== Boot time ===
As boot time fsck is expected to run without user intervention, it generally defaults to not perform any destructive operations. This may be in the form of a read-only check (failing whenever issues are found), or more commonly, a "preen" {{code|-p}} mode that only fixes innocuous issues commonly found after an unclean shutdown (i.e. crash, power fail).<ref name=FreeBSD/> 

ext2/3/4 offers an option to force a boot-time check after a specified number of mounts, so that periodic checking can be done.<ref>{{man|8|tune2fs|Linux}}</ref>

Some modern file systems do not require fsck to be at boot after an unclean shutdown. Some examples are:
* [[XFS]], a [[journaling file system]]. It has a dummy fsck which does nothing<ref>{{man|8|fsck.xfs|Linux}}: "XFS is a journaling filesystem and performs recovery at mount(8) time if necessary"</ref> and an actual <code>xfs_repair</code> tool to be run when problems are suspected.
* [[Unix File System|UFS2]] file system in [[FreeBSD]], which can delay the check to background if [[soft updates]] are enabled.<ref>{{man|8|fsck_ffs|FreeBSD}}</ref> As a result, it is usually not necessary to wait for fsck to finish before accessing the disk. This design is reflected by the {{code|-F}} flag used at boot.<ref name=FreeBSD/>
* [[ZFS]] and [[Btrfs]], two full [[copy-on-write]] file systems. They avoid in-place changes to assure levels of consistency similar to a journal. They also provide a dummy fsck.<ref>{{man|8|fsck.btrfs|Linux}}, : "do nothing, successfully" "Traditional filesystems need to run their respective fsck utility in case the filesystem was not unmounted cleanly and the log needs to be replayed before mount. This is not needed for BTRFS."</ref> <code>btrfs-check</code> is still available to check for suspected problems in filesystem structure (e.g. when a software bug or hardware issue is suspected).

Independent of checking the file system structure, modern file systems may offer a [[data scrubbing]] tool to check for silent corruption in stored data against a mirror or a [[checksum]]. Scrubs tend to be slow as they cover all data on a disk, but periodic runs can defend against [[data rot]] and help identify failing drives.<ref>{{cite web |last1=Swearingen |first1=Cindy |title=Scheduled Pool Scrubs in Oracle Solaris ZFS |url=https://blogs.oracle.com/solaris/post/scheduled-pool-scrubs-in-oracle-solaris-zfs}}</ref>