The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,056 other followers

MacOS: Checking a disk for bad blocks

Posted by jpluimers on 2020/03/13

Hardware fails, but most disk tools on MacOS only check logical disk structures, not bad blocks.

Luckily, fsck_hfs can, though Apple is a bit secretive on it: [WayBack] Page Not Found – Apple Developer: ManPages/man8/fsck_hfs.8.html is empty, but there is [WayBack] man page fsck_hfs section 8 and the gist below.

Disk volumes on MacOS use a successor of HFS called HFS Plus – Wikipedia, but the tooling never changed names.

I got at the below parameters through [

This is the disk check command:

# sudo fsck_hfs -dylS /dev/disk3s1
** /dev/rdisk3s1 (NO WRITE)
    Using cacheBlockSize=32K cacheTotalBlock=65536 cacheSize=2097152K.
Scanning entire disk for bad blocks
   Executing fsck_hfs (version hfs-407.50.6).
** Performing live verification.
** Checking Journaled HFS Plus volume.
   The volume name is SanDisk400GB
** Checking extents overflow file.
** Checking catalog file.
** Checking extended attributes file.
** Checking volume bitmap.
** Checking volume information.
** The volume SanDisk400GB appears to be OK.
    CheckHFS returned 0, fsmodified = 0

The italic part is the bad block scanning. The normal part the hfs scanning, which will continue even after finding bad blocks.

If bad blocks are found, output looks more like on the right. If it looks like that, basically you know a disk is toast.

It can be slow, as I did not specify a cache, so it defaults to 32 Kibibyte. You can increase that by adding for instance -c 512m  for 512 Mebibyte cache, just read the short help or man page below.

This tremendously helps checking volumes containing many files, for instance [WayBack] Checking Very Large Time Machine Volumes – Mac OS X Hints

#c fsck_hfs -h
fsck_hfs: illegal option -- h
usage: fsck_hfs [-b [size] B [path] c [size] e [mode] ESdfglx m [mode] npqruy] special-device
  b size = size of physical blocks (in bytes) for -B option
  B path = file containing physical block numbers to map to paths
  c size = cache size (ex. 512m, 1g)
  e mode = emulate 'embedded' or 'desktop'
  E = exit on first major error
  d = output debugging info
  f = force fsck even if clean (preen only) 
  g = GUI output mode
  x = XML output mode
  l = live fsck (lock down and test-only)
  m arg = octal mode used when creating lost+found directory 
  n = assume a no response 
  p = just fix normal inconsistencies 
  q = quick check returns clean, dirty, or failure 
  r = rebuild catalog btree 
  S = Scan disk for bad blocks
  u = usage 
  y = assume a yes response

or the man page:

FSCK_HFS(8) – System Manager’s Manual


fsck_hfs – HFS file system consistency check


fsck_hfs -q [-dfspecial …
fsck_hfs -p [-dfspecial …
fsck_hfs [-n | -y | -r] [-dfgxlES] [-D flags] [-b size] [-B path] [-m mode] [-c size] [-R flagsspecial …


The fsck_hfs utility verifies and repairs standard HFS and HFS+ file systems.

The first form of fsck_hfs quickly checks the specified file systems to determine whether they were cleanly unmounted.

The second form of fsck_hfs preens the specified file systems. It is normally started by fsck(8) run from /etc/rc.bootduring automatic reboot, when a HFS file system is detected. When preening file systems, fsck_hfs will fix common inconsistencies for file systems that were not unmounted cleanly. If more serious problems are found, fsck_hfs does not try to fix them, indicates that it was not successful, and exits.

The third form of fsck_hfs checks the specified file systems and tries to repair all detected inconsistencies.

If no options are specified fsck_hfs will always check and attempt to fix the specified file systems.

The options are as follows:

-c size

Specify the size of the cache used by fsck_hfs internally. Bigger size can result in better performance but can result in deadlock when used with -l option. Size can be specified as a decimal, octal, or hexadecimal number. If the number ends with a “k”, “m”, or “g”, the number is multiplied by 1024 (1K), 1048576 (1M), or 1073741824 (1G), respectively.


Display debugging information. This option may provide useful information when fsck_hfs cannot repair a damaged file system.

-D flags

Print extra debugging information. The flags are a bitmap that control which kind of debug information is printed. The following values are currently implemented:


Informational messages


Error messages


Extended attributes related messages


Overlapped extents related messages

-b size

Specify the size, in bytes, of the physical blocks used by the -B option.

-B path

Print the files containing the physical blocks listed in the file path. The file should contain one or more decimal, octal (with leading 0) or hexadecimal (with leading 0x) numbers separated by white space. The physical block numbers are relative to the start of the partition, so if you have block numbers relative to the start of the device, you will have to subtract the block number of the start of the partition. The size of a physical block is given with the -b option; the default is 512 bytes per block.


When used with the -p option, force fsck_hfs to check `clean’ file systems, otherwise it means force fsck_hfs to check and repair journaled HFS+ file systems.


Causes fsck_hfs to generate its output strings in GUI format. This option is used when another application with a graphical user interface (like Mac OS X Disk Utility) is invoking the fsck_hfs tool.


Causes fsck_hfs to generate its output strings in XML (plist) format. This option implies the -g option.


Lock down the file system and perform a test-only check. This makes it possible to check a file system that is currently mounted, although no repairs can be made.

-m mode

Mode is an octal number that will be used to set the permissions for the lost+found directory when it is created. The lost+found directory is only created when a volume is repaired and orphaned files or directories are detected.fsck_hfs places orphaned files and directories into the lost+found directory (located at the root of the volume). The default mode is 01777.


Preen the specified file systems.


Causes fsck_hfs to quickly check whether the volume was unmounted cleanly. If the volume was unmounted cleanly, then the exit status is 0. If the volume was not unmounted cleanly, then the exit status will be non-zero. In either case, a message is printed to standard output describing whether the volume was clean or dirty.


Always attempt to repair any damage that is found.


Never attempt to repair any damage that is found.


Cause fsck_hfs to exit (with a value of 47) if it encounters any major errors. A “major error” is considered one which would impact using the volume in normal usage; an inconsistency which would not impact such use is considered “minor” for this option. Only valid with the -n option.


Cause fsck_hfs to scan the entire device looking for I/O errors. It will attempt to map the blocks with errors to names, similar to the -B option.

-R flags

Rebuilds the requested btree. The following flags are supported:


Attribute btree


Catalog btree


Extents overflow btree

Rebuilding a btree will only work if there is enough free space on the file system for the new btree file, and if fsck_hfsis able to traverse each of the nodes in the requested btree successfully. Rebuilding btrees is not supported on HFS Standard volumes.


Rebuild the catalog btree. This is synonymous with -Rc.

Because of inconsistencies between the block device and the buffer cache, the raw device should always be used.


fsck_hfs indicates some status by exit value. The current list of exit status results is:


No errors found, or successfully repaired.


A quick-check (the -n option) found a dirty filesystem; no repairs were made. There is a potential corruption in the filesystem, and either the journal could not be read, or a runtime corruption was present so the HFS Volume Inconsistent bit was set.


During boot, the root filesystem was found to be dirty; repairs were made, and the filesystem was remounted. The system should be rebooted.


A corrupt filesystem was found during a check, or repairs did not succeed.


A major error was found with -E.




fsck_hfs is not able to fix some inconsistencies that it detects.


The fsck_hfs command appeared in Mac OS X Server 1.0 .

Mac OS X – August 5, 2008


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: