Does anyone still need to create legacy HFS filesystems?

Jim Meyering jim at meyering.net
Fri Feb 3 19:47:26 UTC 2012


Chris Murphy wrote:

> On Feb 3, 2012, at 6:56 AM, Jim Meyering wrote:
>
>> Matthew Garrett wrote:
>>> There's various issues with the hfsplus utilities we ship at the moment,
>>> including the fact that fsck.hfsplus crashes on 64-bit. I'd like to
>>
>> Glad you're looking at this.  I noticed that recently, too.
>> I wanted to use fsck.hfsplus in a test to verify that parted's
>> newly-revived FS-resizing code produces something reasonable,
>> but fsck.hfsplus itself segfaults.
>
> On the issue of HFSJ resizing, I may have found a major discrepancy
> between reality and Apple's documentation. I'm skeptical that the
> current resizing code is going to work on large disks at all until
> it's updated to handle a jhdr_size of 4096 bytes for disks with a 512
> byte sector size. Presently the code interprets jhdr_size as the
> disk's sector size. A difference between the two causes resizing to
> fail. I'm seeing resizing fail with virtual and real disks of 2TB or
> greater in size. I do not know what the failure threshold is in terms
> of volume or disk size, but it appears jhdr_size depends on the size
> of the volume, not the size of the disk sectors, contrary to Apple's
> documentation.
>
>
> http://developer.apple.com/legacy/mac/library/#technotes/tn/tn1150.html
>
> jhdr_size - The size of the journal header, in bytes. The journal
> header always occupies exactly one sector so that it can be updated
> atomically. Therefore, this value is equal to the sector size (for
> example, 2048 on many types of optical media).

Right.  The code explicitly rejects any attempt to resize a partition
on a disk with sector size != 512.  Due to this confusion with
jhdr_size, at least for now, I do not plan to change that bit.

Maybe someone who is motivated and capable will submit a patch,
once the resizing code is back on parted's master branch.


More information about the devel mailing list