Re: jhfs+ question, jhdr size
Re: jhfs+ question, jhdr size
- Subject: Re: jhfs+ question, jhdr size
- From: Mark Day <email@hidden>
- Date: Mon, 06 Feb 2012 10:00:44 -0800
On Feb 4, 2012, at 10:25 AM, Chris Murphy <email@hidden> wrote:
> I'm finding a discrepancy between available (legacy) documentation regarding jhdr_size and reality on large disks, equal to or greater than 2TB.
>
>> https://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).
>
> However, I'm finding on at least 2+TB disks, the jhdr_size is not 512 bytes, but rather 4096 bytes. This is with real physical disks as well as virtual disks, neither of which are 4Kn disks. When the disk is at or below 1TB in size, the jhdr_size is 512. So somewhere in between 1TB and 2TB, jhdr_size jumps to 4096, being apparently related to disk or volume size, rather than sector size as documentation states.
>
> So I'm wondering if something has changed and if there is newer documentation that describes the expected behavior?
Sorry for the confusion. Something changed (years ago), and the documentation hasn't been updated. I hope to get started on an update for that technote soon, and I've made a note to address this issue.
Strictly speaking, the jhdr_size needs to be a multiple of the physical sector size (can't be a fraction of the physical sector size) so that it can be updated without a read-modify-write. Ideally, it should be equal to the physical sector size. The actual journal header is very small, and will fit within a single sector. So even if jhdr_size is larger than a single sector, the journal header update will be atomic as long as the drive atomically writes individual sectors (even if it does not atomically write a multi-sector write).
For those who are wondering what happened...
Several major releases ago (Leopard? Tiger? I can't remember which one it was), the I/O Kit portion of the I/O stack added support for 64-bit disk block numbers, but the BSD part of the kernel was still only using signed 32-bit block numbers. We could only use 31 bits for the block number. For 512-byte sectors, that would have limited us to 1TiB volumes. What we did was to tell the driver to switch to a larger logical block size; we started at 4KB, and then scaled up as needed to keep the block numbers fitting in 31 bits. The value you're seeing in jhdr_size is this artificially large logical block size. That hack stayed in place longer than we would have liked.
We have had to gradually evolve that bit of the code to allow some backwards compatibility. We started by fixing the code to allow either the real physical sector size, or the artificially inflated value, but default to the artificially inflated value (for backwards compatibility with the previous major OS version). We had to adapt the journal replay code to temporarily switch the logical block size if the value in jhdr_size was not the physical sector size, so that the journal could be replayed safely. Once those changes had been shipping long enough, we changed the default jhdr_size to be the physical sector size. For volumes formatted in Lion, you should see jhdr_size be equal to the physical block size, even one disks over 1TB.
> Thanks,
>
> Chris Murphy
-Mark
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden