Looking at what's in the patch queue, but not in the series file:
ext4-fix-hang-due-to-corrupted-jinode.patch
ext4-new-defm-options
ext4-online-resize-fix-for-group-descriptor-corruption.patch
Fix-EXT_MAX_BLOCK.patch
jbd2-dio-kjournal-race-EIO.patch
jbd-dio-kjournal-race-EIO.patch
ext2-printk-throttling
ext3_dx_readdir_hash_collision_fix.patch
ext3-printk-throttling
ext3_truncate_block_allocated_on_a_failed_ext3_write_begin.patch
Some of these are probably intentional (I think Ted has the printk
throttling stuff queued up to send) but have any of these simply gotten
lost somehow? Or merged upstream (or obsoleted) but not removed?
At least this one seems to be already applied:
ext4-online-resize-fix-for-group-descriptor-corruption.patch
so should probably be removed from git.
Unless someone knows offhand about the others, I can dig in and see what
might be going on....
For example:
http://repo.or.cz/w/ext4-patch-queue.git?a=commitdiff;h=70e9eefe6c0178e87068f675486a61727a1a48fb
dropped the jbd2-dio-kjournal-race-EIO.patch patch but from the commit
message, it's not clear that it was intentional...?
Thanks,
-Eric
On Sun, Sep 14, 2008 at 02:11:08PM -0700, Eric Sandeen wrote:
> Looking at what's in the patch queue, but not in the series file:
>
> ext4-fix-hang-due-to-corrupted-jinode.patch
> ext4-new-defm-options
> ext4-online-resize-fix-for-group-descriptor-corruption.patch
> Fix-EXT_MAX_BLOCK.patch
> jbd2-dio-kjournal-race-EIO.patch
> jbd-dio-kjournal-race-EIO.patch
>
> Some of these are probably intentional (I think Ted has the printk
> throttling stuff queued up to send) but have any of these simply gotten
> lost somehow? Or merged upstream (or obsoleted) but not removed?
Well, all of the patches in the ext3 directory are non-ext4 patches
which I sent to akpm on Friday or Saturday; I decided to check them
into the patch queue to make sure they don't get lost. I'll remove
them when they are confirmed in -mm. These would be:
> ext2-printk-throttling
> ext3_dx_readdir_hash_collision_fix.patch
> ext3-printk-throttling
> ext3_truncate_block_allocated_on_a_failed_ext3_write_begin.patch
Some of the patches were ones that fixed bugs introduced in other
patches, and were folded into a parent patch. This was the case for
ext4-fix-hang-due-to-corrupted-jinode.patch, which was folded into the
patch that ultimately became commit 678aaf48 in the mainline Linux
tree.
Ext4-new-defm-options was a patch I was working on that never got
finished. It probably shouldn't have gotten checked into the patch
queue.
Girish's Fix-EXT_MAX_BLOCK.patch caused regression failures, so it was
dropped from the patch series. I don't think anyone ever went back to
figure out why it was causing the ext4 tree to blow up.
As far as jbd2-dio-kjournal-race-EIO.patch and
jbd-dio-kjournal-race-EIO.patch are concerned,
jbd2-dio-kjournal-race-EIO.patch doesn't even apply any more. I'm
guess it was fixed in some other way for jbd2. It looks the jbd patch
could apply, but if it's still a valid fix, it should be fed through
akpm. Mingming, do you know what the status of these two patches are?
- Ted
Theodore Tso wrote:
> On Sun, Sep 14, 2008 at 02:11:08PM -0700, Eric Sandeen wrote:
>> Looking at what's in the patch queue, but not in the series file:
>>
>> ext4-fix-hang-due-to-corrupted-jinode.patch
>> ext4-new-defm-options
>> ext4-online-resize-fix-for-group-descriptor-corruption.patch
>> Fix-EXT_MAX_BLOCK.patch
>> jbd2-dio-kjournal-race-EIO.patch
>> jbd-dio-kjournal-race-EIO.patch
>>
>> Some of these are probably intentional (I think Ted has the printk
>> throttling stuff queued up to send) but have any of these simply gotten
>> lost somehow? Or merged upstream (or obsoleted) but not removed?
>
> Well, all of the patches in the ext3 directory are non-ext4 patches
> which I sent to akpm on Friday or Saturday; I decided to check them
> into the patch queue to make sure they don't get lost. I'll remove
> them when they are confirmed in -mm. These would be:
>
>> ext2-printk-throttling
>> ext3_dx_readdir_hash_collision_fix.patch
>> ext3-printk-throttling
>> ext3_truncate_block_allocated_on_a_failed_ext3_write_begin.patch
>
> Some of the patches were ones that fixed bugs introduced in other
> patches, and were folded into a parent patch. This was the case for
> ext4-fix-hang-due-to-corrupted-jinode.patch, which was folded into the
> patch that ultimately became commit 678aaf48 in the mainline Linux
> tree.
Ok that's what I thought.
> Ext4-new-defm-options was a patch I was working on that never got
> finished. It probably shouldn't have gotten checked into the patch
> queue.
Ok.
> Girish's Fix-EXT_MAX_BLOCK.patch caused regression failures, so it was
> dropped from the patch series. I don't think anyone ever went back to
> figure out why it was causing the ext4 tree to blow up.
Ok. Maybe it'd be better for something like that to comment it out of
the patch series, with a reason why? *shrug*
> As far as jbd2-dio-kjournal-race-EIO.patch and
> jbd-dio-kjournal-race-EIO.patch are concerned,
> jbd2-dio-kjournal-race-EIO.patch doesn't even apply any more. I'm
> guess it was fixed in some other way for jbd2. It looks the jbd patch
> could apply, but if it's still a valid fix, it should be fed through
> akpm. Mingming, do you know what the status of these two patches are?
>
> - Ted
Great - owners looking over these orphaned/lost patches is probably the
best approach. :)
Thanks,
-Eric
On Sep 14, 2008 17:34 -0400, Theodore Ts'o wrote:
> Girish's Fix-EXT_MAX_BLOCK.patch caused regression failures, so it was
> dropped from the patch series. I don't think anyone ever went back to
> figure out why it was causing the ext4 tree to blow up.
I think we have an updated version of this patch. Girish?
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
在 2008-09-14日的 17:34 -0400，Theodore Tso写道：
> On Sun, Sep 14, 2008 at 02:11:08PM -0700, Eric Sandeen wrote:
> > Looking at what's in the patch queue, but not in the series file:
> >
> > ext4-fix-hang-due-to-corrupted-jinode.patch
> > ext4-new-defm-options
> > ext4-online-resize-fix-for-group-descriptor-corruption.patch
> > Fix-EXT_MAX_BLOCK.patch
> > jbd2-dio-kjournal-race-EIO.patch
> > jbd-dio-kjournal-race-EIO.patch
> >
> > Some of these are probably intentional (I think Ted has the printk
> > throttling stuff queued up to send) but have any of these simply gotten
> > lost somehow? Or merged upstream (or obsoleted) but not removed?
>
> Well, all of the patches in the ext3 directory are non-ext4 patches
> which I sent to akpm on Friday or Saturday; I decided to check them
> into the patch queue to make sure they don't get lost. I'll remove
> them when they are confirmed in -mm. These would be:
>
> > ext2-printk-throttling
> > ext3_dx_readdir_hash_collision_fix.patch
> > ext3-printk-throttling
> > ext3_truncate_block_allocated_on_a_failed_ext3_write_begin.patch
>
> Some of the patches were ones that fixed bugs introduced in other
> patches, and were folded into a parent patch. This was the case for
> ext4-fix-hang-due-to-corrupted-jinode.patch, which was folded into the
> patch that ultimately became commit 678aaf48 in the mainline Linux
> tree.
>
> Ext4-new-defm-options was a patch I was working on that never got
> finished. It probably shouldn't have gotten checked into the patch
> queue.
>
> Girish's Fix-EXT_MAX_BLOCK.patch caused regression failures, so it was
> dropped from the patch series. I don't think anyone ever went back to
> figure out why it was causing the ext4 tree to blow up.
>
> As far as jbd2-dio-kjournal-race-EIO.patch and
> jbd-dio-kjournal-race-EIO.patch are concerned,
> jbd2-dio-kjournal-race-EIO.patch doesn't even apply any more. I'm
> guess it was fixed in some other way for jbd2. It looks the jbd patch
> could apply, but if it's still a valid fix, it should be fed through
> akpm. Mingming, do you know what the status of these two patches are?
>
Hi Ted, Eric,
These two patches(jbd and jbd2) could be safely removed from patch
queue, the updated version were pushed to linus from Andrew. I have
removed the staled patches from patch queue
> - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html