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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
