lkml.org 
[lkml]   [2009]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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.
>


\
 
 \ /
  Last update: 2009-01-07 00:29    [W:0.124 / U:1.820 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site