Messages in this thread | | | Date | Tue, 6 Jan 2009 15:26:04 -0800 | From | "Warren Turkal" <> | Subject | Re: 2.6.29 -mm merge plans |
| |
I have a drive at home with the condition. So empirically, it can happen.
I would also argue that having a journal bit set and then saying that the journal info block is at 0 makes no sense anyhow since the first 1024 bytes of the volume must be empty on HFS+.
And, I found the previous code from Apple saying that a 0 in the journal_info_block field indicated that there was no journal.
Is there anything else I should be doing?
wt
On Tue, Jan 6, 2009 at 3:19 PM, Christoph Hellwig <hch@infradead.org> wrote: > On Tue, Jan 06, 2009 at 03:17:47PM -0800, Andrew Morton wrote: >> > I'm pretty sure we already had a version better than that in your >> > tree on the list. But I've lost track and we should just restart >> > the review cycle on -fsdevel. >> >> Yeah, I have the three hfs patches: >> >> hfsplus-identify-journal-info-block-in-volume-header.patch >> hfsplus-fix-journal-detection.patch >> hfs-add-basic-export-support.patch >> >> in a holding pattern awaiting a second round, due to laggy, incomplete >> and confusing noises from various people. It all needs a revisit. > > The first two are not for me to decide. They look fine code-wise, > but IIRC Roman had some issues with wether the condition should be > possible at all. > > The third one is where I requested a respin, and I'm pretty sure I've > seen a version with some improvement over the one in your tree. Let's > get the latests version back on -fsdevel and review it again. > > The one in your tree certainly is not ready. >
| |