Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*writeout\s+stalls\s+in\s+current\s+\-git\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*writeout\s+stalls\s+in\s+current\s+\-git\s*$/: 18 ]

Total 18 documents matching your query.

1. Re: writeout stalls in current -git (score: 1): Author: "Torsten Kaiser" <just.for.lkml@xxxxxxxxxxxxxx>; Date: Fri, 2 Nov 2007 22:02:23 +0100; It's 2.6.23-mm1 with only some small fixes. In it's broken-out directory I see: git-xfs.patch and writeback-fix-periodic-superblock-dirty-inode-flushing.patch writeback-fix-time-ordering-of-the-per-s; /archives/xfs/2007-11/msg00024.html (14,001 bytes)
2. Re: writeout stalls in current -git (score: 1): Author: "Torsten Kaiser" <just.for.lkml@xxxxxxxxxxxxxx>; Date: Sun, 4 Nov 2007 12:19:19 +0100; I can now confirm, that I see this also with the current mainline-git-version I used 2.6.24-rc1-git-b4f555081fdd27d13e6ff39d455d5aefae9d2c0c plus the fix for the sg changes in ieee1394. Bisecting wou; /archives/xfs/2007-11/msg00026.html (18,455 bytes)
3. Re: writeout stalls in current -git (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Mon, 5 Nov 2007 12:45:10 +1100; Ok, so it's probably a side effect of the writeback changes. Attached are two patches (two because one was in a separate patchset as a standalone change) that should prevent async writeback from bloc; /archives/xfs/2007-11/msg00034.html (11,474 bytes)
4. Re: writeout stalls in current -git (score: 1): Author: "Torsten Kaiser" <just.for.lkml@xxxxxxxxxxxxxx>; Date: Mon, 5 Nov 2007 08:01:41 +0100; Applied both patches against the kernel mentioned above. This blows up at boot: [ 80.807589] Filesystem "dm-0": Disabling barriers, not supported by the underlying device [ 80.820241] XFS mounting fi; /archives/xfs/2007-11/msg00038.html (14,496 bytes)
5. Re: writeout stalls in current -git (score: 1): Author: "Torsten Kaiser" <just.for.lkml@xxxxxxxxxxxxxx>; Date: Mon, 5 Nov 2007 19:27:16 +0100; Now testing v2.6.24-rc1-650-gb55d1b1+ the fix for the missapplied raid5-patch Applying your two patches ontop of that does not fix the stalls. vmstat 10 output from unmerging (uninstalling) a kernel:; /archives/xfs/2007-11/msg00039.html (14,872 bytes)
6. Re: writeout stalls in current -git (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Tue, 6 Nov 2007 15:25:27 +1100; So you are having RAID5 problems as well? I'm struggling to understand what possible changed in XFS or writeback that would lead to stalls like this, esp. as you appear to be removing files when the; /archives/xfs/2007-11/msg00043.html (14,213 bytes)
7. Re: writeout stalls in current -git (score: 1): Author: "Torsten Kaiser" <just.for.lkml@xxxxxxxxxxxxxx>; Date: Tue, 6 Nov 2007 08:10:21 +0100; The first 2.6.24-rc1-git-kernel that I patched with your patches did not boot for me. (Oops send in one of my previous mails) But given that the stacktrace was not xfs related and I had seen this pat; /archives/xfs/2007-11/msg00045.html (18,139 bytes)
8. Re: writeout stalls in current -git (score: 1): Author: Peter Zijlstra <peterz@xxxxxxxxxxxxx>; Date: Tue, 06 Nov 2007 20:01:22 +0100; Just a crazy idea,.. Could there be a set_page_dirty() that doesn't have balance_dirty_pages() call near? For example modifying meta data in unlink? Such a situation could lead to an excess of dirty; /archives/xfs/2007-11/msg00057.html (10,197 bytes)
9. Re: writeout stalls in current -git (score: 1): Author: "Torsten Kaiser" <just.for.lkml@xxxxxxxxxxxxxx>; Date: Tue, 6 Nov 2007 21:26:05 +0100; Only if accounting of the dirty pages is also broken. In the unmerge testcase I see most of the time only <200kb of dirty data in /proc/meminfo. The system has 4Gb of RAM so I'm not sure if it should; /archives/xfs/2007-11/msg00058.html (11,901 bytes)
10. Re: writeout stalls in current -git (score: 1): Author:; Date: Fri, 2 Nov 2007 22:02:23 +0100; It's 2.6.23-mm1 with only some small fixes. In it's broken-out directory I see: git-xfs.patch and writeback-fix-periodic-superblock-dirty-inode-flushing.patch writeback-fix-time-ordering-of-the-per-s; /archives/xfs/2007-11/msg00340.html (14,001 bytes)
11. Re: writeout stalls in current -git (score: 1): Author:; Date: Sun, 4 Nov 2007 12:19:19 +0100; I can now confirm, that I see this also with the current mainline-git-version I used 2.6.24-rc1-git-b4f555081fdd27d13e6ff39d455d5aefae9d2c0c plus the fix for the sg changes in ieee1394. Bisecting wou; /archives/xfs/2007-11/msg00342.html (18,455 bytes)
12. Re: writeout stalls in current -git (score: 1): Author:; Date: Mon, 5 Nov 2007 12:45:10 +1100; Ok, so it's probably a side effect of the writeback changes. Attached are two patches (two because one was in a separate patchset as a standalone change) that should prevent async writeback from bloc; /archives/xfs/2007-11/msg00350.html (11,474 bytes)
13. Re: writeout stalls in current -git (score: 1): Author:; Date: Mon, 5 Nov 2007 08:01:41 +0100; Applied both patches against the kernel mentioned above. This blows up at boot: [ 80.807589] Filesystem "dm-0": Disabling barriers, not supported by the underlying device [ 80.820241] XFS mounting fi; /archives/xfs/2007-11/msg00354.html (14,496 bytes)
14. Re: writeout stalls in current -git (score: 1): Author:; Date: Mon, 5 Nov 2007 19:27:16 +0100; Now testing v2.6.24-rc1-650-gb55d1b1+ the fix for the missapplied raid5-patch Applying your two patches ontop of that does not fix the stalls. vmstat 10 output from unmerging (uninstalling) a kernel:; /archives/xfs/2007-11/msg00355.html (14,872 bytes)
15. Re: writeout stalls in current -git (score: 1): Author:; Date: Tue, 6 Nov 2007 15:25:27 +1100; So you are having RAID5 problems as well? I'm struggling to understand what possible changed in XFS or writeback that would lead to stalls like this, esp. as you appear to be removing files when the; /archives/xfs/2007-11/msg00359.html (14,213 bytes)
16. Re: writeout stalls in current -git (score: 1): Author:; Date: Tue, 6 Nov 2007 08:10:21 +0100; The first 2.6.24-rc1-git-kernel that I patched with your patches did not boot for me. (Oops send in one of my previous mails) But given that the stacktrace was not xfs related and I had seen this pat; /archives/xfs/2007-11/msg00361.html (18,139 bytes)
17. Re: writeout stalls in current -git (score: 1): Author:; Date: Tue, 06 Nov 2007 20:01:22 +0100; Just a crazy idea,.. Could there be a set_page_dirty() that doesn't have balance_dirty_pages() call near? For example modifying meta data in unlink? Such a situation could lead to an excess of dirty; /archives/xfs/2007-11/msg00373.html (10,197 bytes)
18. Re: writeout stalls in current -git (score: 1): Author:; Date: Tue, 6 Nov 2007 21:26:05 +0100; Only if accounting of the dirty pages is also broken. In the unmerge testcase I see most of the time only <200kb of dirty data in /proc/meminfo. The system has 4Gb of RAM so I'm not sure if it should; /archives/xfs/2007-11/msg00374.html (11,901 bytes)

Current List: 1 - 18
Page: [1]