> … more than enough contiguous free space for a rebuilt catalog B-tree to be contiguous …

The freely available demo version of iDefrag can:

a) easily show the size, in GB, of the catalog B-tree (shown as the Catalog File)

b) offer a rough guide, with its layout representation of the disk, to the sizes of contiguous free spaces.

PhotoMau wrote:

 

From the discussions, what I gather are some of the problems people encounter:

1. There is an issue with the disk and fsck_hfs hangs during the safe boot.
   1. Resolve this by: Disk Warrior, or by running fsck_hfs -fy from the terminal in a recovery mode boot. Occasionally the diskutility can also fix this issue.
   2. Usually after that the safe boot works.

I tried to run fsck_hfs but it says something about a special device not being specified.  I tried /sbin/fsck_hfs but that did'nt work either.  Anyone have a path to root or a way to force it?   fsck -fy works as usual....

This sounds like a general question about fsck_hfs, not specific to this issue with safe boot.

fsck_hfs(8) OS X Manual Page

The reason I'm asking is because I cannot safeboot in 10.8.3

If you see this –

fsck_hfs: missing special-device

– then you need general help with interpreting the manual page for fsck_hfs, and with working at the command line in Terminal. With respect, those things are beyond the scope of this topic; such help could be unexpectedly convoluted in a topic that's already long.

For the questions about usage of fsck_hfs, maybe aim for

OS X Mountain Lion

Thanks  bunch. This worked out well and saved me the trauma of re-installing.

@Jefferis, I believe you can just run "/sbin/fsck -fy" and that runs fsck_hfs. I haven't seen anyone list any other specific options to use in his thread.

Unfortunately that doesn't work me and it doesn't seemed to haved worked for many others either. DiskWarrior seems to have worked for some. but I'm hesitating on that $99 price tag.

joulesbaud wrote:

 

Thanks  bunch. This worked out well and saved me the trauma of re-installing.

On page 12 of a thread, the phrase "This worked out well" isn't terribly informative. Could you possibly replace the pronoun "This" with some actual information about what exactly you did, how you did it, and what the result was.

Thank you.

It was in response to a post on page 9. In theory the link should work.

(Some users of Apple Support Communities will be taken to the wrong page, sometimes with the page number unidentifiable, but that bug with service is off-topic.)

Same issues for me

Mountain Lion 10.8.3

MBP 2012, 16gb Crucial Ram, OWC SSD.

FWIW

- Installed Parallels

- Previously had a Firmware password set, and Encrypted volume

I'm wondering if maybe the SSD is the common issue here?

MacPro. No SSD. Same issue.

Unfortunately SSD is not common.

13" 2011 Early Macbook Pro with 500GB HDD has the same problem.

8GB out of factory RAM with 10.8 clean installed a while ago. Updated to 10.8.3.

I tried

sudo nvram boot-args="-x -v maxmem=4"

to see whether RAM size matters. Failed.

I also checked that my Open Firmware Password is disabled.

Now I wonder what may change when a RAM is removed.

Well, I don't think the content on startup disk really matters.

I don't know whether maxmem=4 actually affected memory, but I just removed one of my two original Apple RAM and successfully booted into Safe Mode. I then added it back and tried again, which was a fail.

So I think if it's not the size, it may be the motherboard or that specific RAM socket.

I wonder if that test is only x86 aka 32-bit. Since OS X is 64-bit there may be difference.

On a Mac mini 2012 with 16 GByte RAM running 10.8.2 and 10.8.3, safe mode was always stuck during file system checking at "Checking extended attributes file". As fsck_hfs -fy /dev/rdiskX in Terminal.app of rescue mode (CMD R) always completed successfully, I searched for the differences between rescue mode and safe mode.

The difference is, that rescue mode somehow starts with a 32bit kernel or is limiting itself to 4 GByte RAM. When starting fsck_hfs in rescue mode it reports "Using ... cacheSize=2097152K" while fsck_hfs in safe mode shows "Using ... cacheSize=3145728K".

That means, fsck_hfs in Mac OS X 10.8.2 and 10.8.3 is somehow broken when using more than 2 GByte RAM as cache. Fortunately, you can limit the cache size with the parameter -c, i.e. /sbin/fsck_hfs -c2g for 2 GByte cache size.

You can enable the verbose messages in safe mode with sudo nvram boot-args="-x -v". Take care, that this setting is permanent! If you are always stuck in safe mode you need to press ALT CMD P R to reset the PRAM and NVRAM during power on. Otherwise, if all went well, just remove the parameters with sudo nvram boot-args="".

To finally get successful through the safe mode, you need to add the -c2g parameter to the fsck call the safe mode is using automatically during boot.

Open Terminal.app and enter:

nano /tmp/fsck_hfs

In text editor "nano" enter the following 3 lines:

#!/bin/sh

echo /sbin/fsck_hfs -c2g $*

/sbin/fsck_hfs_orig -c2g $*

and save the file with ctrl x.

sudo mv -n /sbin/fsck_hfs /sbin/fsck_hfs_orig

sudo mv -n /tmp/fsck_hfs /sbin/fsck_hfs

sudo chown root:wheel /sbin/fsck_hfs

sudo chmod 555 /sbin/fsck_hfs

Verify with:

ls -l /sbin/fsck_hfs*

This should report, with different file dates than mine:

-r-xr-xr-x  1 root  wheel      67 May 17 23:00 /sbin/fsck_hfs

-r-xr-xr-x  1 root  wheel  529472 Oct 19  2012 /sbin/fsck_hfs_orig

To reset to the original state later after safe mode or if there are problems with fsck:

sudo mv -n  /sbin/fsck_hfs_workaround

sudo mv -n /sbin/fsck_hfs_orig /sbin/fsck_hfs

Hope that helps,

Holger

(filed as bug id 13928006)