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.