patches in queue but missing from series?
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
Quoted 9 lines · Eric Sandeen
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
Quoted 3 lines
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:
Quoted 4 lines
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
Quoted 24 lines · Theodore Tso
Quoted 9 lines · Eric Sandeen
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
Quoted 3 lines
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:
Quoted 4 lines
ext2-printk-throttling ext3_dx_readdir_hash_collision_fix.patch ext3-printk-throttling ext3_truncate_block_allocated_on_a_failed_ext3_write_begin.patch
Quoted 5 lines
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
678aaf48in the mainline Linux tree.
Ok that's what I thought.
Quoted 3 lines
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.
Quoted 3 lines
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*
Quoted 8 lines
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
Quoted 3 lines · Theodore Ts'o
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.
Quoted 38 lines · 在 2008-09-14日的 17:34 -0400，Theodore Tso写道：
Quoted 9 lines · Eric Sandeen
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
Quoted 3 lines
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:
Quoted 4 lines
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
678aaf48in 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.
Quoted 7 lines
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
Quoted 5 lines
- 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
--
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