Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I use a ramdisk to speed up a git repository with a lot (> 60k) of small (~200 bytes) files.

Is there a way to create a ramdisk with a smaller block size?

share|improve this question
How do you specify the ramdisk now? – Mark Jun 25 '12 at 23:15
diskutil erasevolume HFS+ "ramdisk" hdiutil attach -nomount ram://1165430 – dh82 Jun 26 '12 at 8:59
I would look at hdiutil resize - however does a ramdisk really help in your scenario - test the speed as disk caching might do enough + what happens when osx or something else crashes don't you lose work and defeat the object of version control? – Mark Jun 26 '12 at 9:33
I currently fail to commit the git repository under 10.7 due to a timeout (> 3h) whereas I can finish the exact same operations in 10mins on a standard Ubuntu VirtualBox image running on the very same machine. – dh82 Jun 26 '12 at 23:53
In this case it does not defeat the versioning system since I want to do some expensive rebaseing and version comparisons. – dh82 Jun 26 '12 at 23:54
up vote 1 down vote accepted

Executive summary: I don't believe this is possible, at least not for volumes formatted as HFS+.

My current understanding is that HFS+ chooses its file system block size (separate from the physical device block size) according to a fixed default allocation block size that cannot be manually overruled.

HFS+ Default Allocation Block Size

Discussions in other forums spanning from 2002 to 2011 ( CompGroups, MacRumors among others) suggest using newfs_hfs(8), which has a -b <blocksize> option, to manually set the block size when creating a new file system.

I tried using newfs_hfs on various kinds of partitions, on both .dmg diskimages and on physical SATA hard drives (through SATA<->USB interface) and with various file systems (HFS+, FAT16, FAT32.) When I ran newfs_hfs with different -b sizes (512, 1024, 2048, 4096, 8192,) indeed it reported success in creating the filesystems with the specified block sizes. I could mount & read/write these volumes normally.

But when I examine the test volumes with diskutil info <diskname> (where <diskname> is disk1, disk4, or whatever your disk is), I always see:

Total Size:               104.9 MB (104857600 Bytes) (exactly 204800 512-Byte-Blocks)
Volume Free Space:        102.4 MB (102385664 Bytes) (exactly 199972 512-Byte-Blocks)
Device Block Size:        512 Bytes

Noting that the end of the newfs_hfs(8) man page includes this tidbit:

The newfs_hfs command appeared in Mac OS X Server 1.0 .  As of Mac OS X
10.6, this utility no longer generates HFS standard file systems.

It would appear that OS X 10.8 (and probably 10.7, and perhaps earlier versions) overrides whatever block size newfs_hfs claims to create, in favor of default sizes imposed by a higher authority. (??)

One article I came across suggested using OS X's software-RAID utility to create a RAID mirror. Software RAID allows one to specify a RAID stripe size, but as this is generally geared towards improving throughput for large files rather than tiny ones, I believe the minimum RAID stripe size is 4KB - not useful for your purposes.

share|improve this answer
Awesome! Thanks a lot for the detailed insight! – dh82 Mar 21 '13 at 13:59

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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