When other IO is running sync times go to 10 to 20 minutes
http://bugzilla.kernel.org/show_bug.cgi?id=14830
Alasdair G Kergon <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected] Component|LVM2/DM |ext4 AssignedTo|[email protected] |[email protected] | |g Product|IO/Storage |File System
--- Comment #1 from Alasdair G Kergon <[email protected]> 2010-01-13 19:15:12 --- filesystem or nfs perhaps?
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
http://bugzilla.kernel.org/show_bug.cgi?id=14830
Jan Kara <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #2 from Jan Kara <[email protected]> 2010-01-18 21:50:38 --- There are two issues here - the first is that sync takes long - this is at the level of "don't do it when it hurts" kind of thing ;). So when you do heavy writing and call sync, it simply takes long time to flush all the caches to disk. If you think the time is inappropriately long, we can have a look at it but for that we'd need much more details like amount and nature of data writen (many small files vs a few large ones), time it takes sync to complete, speed of disks for sequential IO...
The second issue is that nfsd blocks as well. Partly this might be because sync blocks writers (so that it can get it's work done in a finite time), partly it might be a limitation of ext4 because all metadata writes go through a journal which has a limited size and thus we have to copy data from the journal to final locations on disk once in a while and that usually leads to all writer processes blocking waiting for the journal space to be freed (which can take a longer time when 'sync' process is making disk busy with data writes).
Note in the log file:
This problem prevents production use of systems using this kernel.
evokes a question: Do you have a kernel which behaved better for you? Which one?
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
http://bugzilla.kernel.org/show_bug.cgi?id=14830
--- Comment #3 from Michael Godfrey <[email protected]> 2010-01-18 23:58:09 ---
Quoted 4 lines
This problem prevents production use of systems using this kernel.
evokes a question: Do you have a kernel which behaved better for you? Which one?
Yes. RHEL5.4 does not show this problem. It is the production system that works in this environment.
The response above is disappointing. Is sync response of 20 minutes, including several task timeouts to be considered "normal?"
Quoted 4 lines
If you think the time is inappropriately long, we can have a look at it but for that we'd need much more details like amount and nature of data writen (many small files vs a few large ones), time it takes sync to complete, speed of disks for sequential IO...
I am sorry to have to tell you that in this environment we do not deal in exclusively small or large files, we actually have quite a few of both. When an rsync which transfers about 50GB of files of various sizes is running, the hung condition is continuous until the rsync completes. This is just a pretty typical load. You could try it yourself. No special sizes of files are required. I think I mentioned that the ext4 LVM is a RAID 50 3ware 9650SE-8LPML, with 8 2T drives. Its throughput for reading and writing is good when the system is not locked up.
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
Quoted 29 lines · [email protected] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=14830
--- Comment #3 from Michael Godfrey <[email protected]> 2010-01-18 23:58:09 ---
Quoted 7 lines
This problem prevents production use of systems using this kernel.
evokes a question: Do you have a kernel which behaved better for you? Which one?
Yes. RHEL5.4 does not show this problem. It is the production system that works in this environment.
The response above is disappointing. Is sync response of 20 minutes, including several task timeouts to be considered "normal?"
Quoted 5 lines
If you think the time is inappropriately long, we can have a look at it but for that we'd need much more details like amount and nature of data writen (many small files vs a few large ones), time it takes sync to complete, speed of disks for sequential IO...
Quoted 11 lines
I am sorry to have to tell you that in this environment we do not deal in exclusively small or large files, we actually have quite a few of both. When an rsync which transfers about 50GB of files of various sizes is running, the hung condition is continuous until the rsync completes. This is just a pretty typical load. You could try it yourself. No special sizes of files are required. I think I mentioned that the ext4 LVM is a RAID 50 3ware 9650SE-8LPML, with 8 2T drives. Its throughput for reading and writing is good when the system is not locked up.
Is it possible that it is something allong the lines of what is described at this link:
http://notemagnet.blogspot.com/2008/08/linux-write-cache-mystery.html
If so a runtime adjustment might help you out.
Chris.
http://bugzilla.kernel.org/show_bug.cgi?id=14830
--- Comment #4 from Anonymous Emailer <[email protected]> 2010-01-19 17:24:49 ---
Reply-To: [email protected]
Quoted 29 lines · [email protected] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=14830
--- Comment #3 from Michael Godfrey <[email protected]> 2010-01-18 23:58:09 ---
Quoted 7 lines
This problem prevents production use of systems using this kernel.
evokes a question: Do you have a kernel which behaved better for you? Which one?
Yes. RHEL5.4 does not show this problem. It is the production system that works in this environment.
The response above is disappointing. Is sync response of 20 minutes, including several task timeouts to be considered "normal?"
Quoted 5 lines
If you think the time is inappropriately long, we can have a look at it but for that we'd need much more details like amount and nature of data writen (many small files vs a few large ones), time it takes sync to complete, speed of disks for sequential IO...
Quoted 11 lines
I am sorry to have to tell you that in this environment we do not deal in exclusively small or large files, we actually have quite a few of both. When an rsync which transfers about 50GB of files of various sizes is running, the hung condition is continuous until the rsync completes. This is just a pretty typical load. You could try it yourself. No special sizes of files are required. I think I mentioned that the ext4 LVM is a RAID 50 3ware 9650SE-8LPML, with 8 2T drives. Its throughput for reading and writing is good when the system is not locked up.
Is it possible that it is something allong the lines of what is described at this link:
http://notemagnet.blogspot.com/2008/08/linux-write-cache-mystery.html
If so a runtime adjustment might help you out.
Chris.
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
http://bugzilla.kernel.org/show_bug.cgi?id=14830
Theodore Tso <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #5 from Theodore Tso <[email protected]> 2010-01-19 19:38:34 --- So the Linux write cache mystery is unlikely to solve the problem since that was talking about backporting some tuning parameters from 2.6.22 to the RHEL/CentOS 2.6.18 kernel, and here the problem seems to be that the sync is taking much longer on a 2.6.31 FC 12 kernel.
So the first thing I notice is the fact that you have the nodelalloc mount
option enabled. Any particular reason why you did that? Try removing that;
one of the reasons why ext4 is generally described as being much better than ext3 with respect to this problem (of the machine becoming unresponsive during
a sync) is because of delayed allocation, and you've turned it off. So try
removing nodelalloc and see if that makes the performance come back.
Another thing that might be worth testing is to see whether an ext3 filesystem
on a 2.6.31 FC 12 kernel behaves any differently. This may be something that
is some kind of VM tuning issue between RHEL 5.4 and a modern kernel; I don't know how many people try running Fedora 12 on a system with large amounts of memory and an NFS load, and maybe there is some kind of tuning issue that has
been exposed. So that's a quick experiment that's worth doing just so we can
figure out where we need to concentrate our diagnostic efforts.
Another thing to try is to do some instrumentation using iostat to see what the system is doing, before, during, and after the sync command.
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
http://bugzilla.kernel.org/show_bug.cgi?id=14830
--- Comment #6 from Michael Godfrey <[email protected]> 2010-01-19 21:56:12 ---
Quoted 2 lines
So the first thing I notice is the fact that you have the nodelalloc mount
option enabled. Any particular reason why you did that?
This was required due to an error in 2.6.30. It is possible that it is no longer needed. I will check.
It is not really feasible to revert to ext3 other than going back to RHEL5 which is what has been done. One of the main purposes of using FC11 was ext4. fsck under ext3 is about 8 hours, under ext4 about 9 minutes. And, ext4 has other well-advertised advantages.
Quoted 2 lines
Another thing to try is to do some instrumentation using iostat to see what the system is doing, before, during, and after the sync command.
I have tried this to some extent. It is not too easy when response is extremely slow.
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
http://bugzilla.kernel.org/show_bug.cgi?id=14830
--- Comment #7 from Michael Godfrey <[email protected]> 2010-01-25 07:38:52 --- I tried the advice above about nodelalloc using a newer kernel.
It had no observable effect, but did not cause problems as it
had before. So, I left it turned off. And, I installed kernel 2.6.31.12-174.2.3.fc12.x86_64.
None of this helped. sync times still at 20 minutes during rsync, and task (sync or rsync) timeouts in /var/log/messages.
I guess that patience is called for here.
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
http://bugzilla.kernel.org/show_bug.cgi?id=14830
--- Comment #8 from Theodore Tso <[email protected]> 2010-01-25 08:27:26 --- Hmm, can you run "iostat 1 | tee iostat.log &", and while that is running, wait for a 15 seconds or so we can capture what things like in steady state, and then type "sync", and note when the sync command was initiated in the
iostat.log file? It would be useful seeing what this looks like on both your
ext3 production server and on the ext4 test server. Do you know if there are any other differences between the two systems, in terms of the workload seen by your production server versus your test server?
Another thing that would be very useful to do is to enable ftrace, and then cd to /sys/kernel/debug/tracing. (This assumes that you have debugfs mounted on/sys/kernel/debug.) Then "echo 1 > events/jbd2/jbd2_run_stats/enable" and
then in a similar fashion, do "cat trace_pipe | tee /tmp/trace.output", wait for four or five data samples from your file system of interest, and then issue the sync command, and let's see what is happening.
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
http://bugzilla.kernel.org/show_bug.cgi?id=14830
--- Comment #9 from Michael Godfrey <[email protected]> 2010-01-25 11:07:46 --- Created an attachment (id=24705)
--> (http://bugzilla.kernel.org/attachment.cgi?id=24705)
Requested iostat.log file
As requested by: Theodore Tso <[email protected]>
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
http://bugzilla.kernel.org/show_bug.cgi?id=14830
--- Comment #10 from Michael Godfrey <[email protected]> 2010-01-25 11:16:16 --- Created an attachment (id=24706)
--> (http://bugzilla.kernel.org/attachment.cgi?id=24706)
messages output with sync running
Additional information for Theodore Tso <[email protected]>
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
http://bugzilla.kernel.org/show_bug.cgi?id=14830
--- Comment #11 from Michael Godfrey <[email protected]> 2010-01-25 11:19:12 --- I have attached the iostat.log and log/messages output.
sync was started after about 4 cycles of iostat.
This was run on the FC12 ext4 system. No testing can be done on the production system.
After kill -9 of the sync run it took about 20 minutes before it died.
Michael
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
Quoted 2 lines · On 11:19, [email protected] wrote:
After kill -9 of the sync run it took about 20 minutes before it died.
I was seeing similar behaviour on one of our servers, and changing the io scheduler to noop fixed things for me. So it seems to be an issue with cfq which is somehow triggered by ext4 but not by ext3.
To change the IO scheduler, just execute
echo noop > /sys/block/sda/queue/scheduler
(replace sda if necessary).
Just my 2 cents
Andre
Signature · 1 line
The only person who always got his work done by Friday was Robinson Crusoe
Quoted 11 lines · Andre Noll
Quoted 2 lines · On 11:19, [email protected] wrote:
After kill -9 of the sync run it took about 20 minutes before it died.
I was seeing similar behaviour on one of our servers, and changing the io scheduler to noop fixed things for me. So it seems to be an issue with cfq which is somehow triggered by ext4 but not by ext3.
To change the IO scheduler, just execute
echo noop >
/sys/block/sda/queue/scheduler
Andre, could you please also test deadline instead of noop? In general, deadline has nearly the same IO behaviour as noop, but still allows simple request merging and is generally a better option than noop.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
Quoted 8 lines · Andre Noll
Quoted 2 lines · On 11:19, [email protected] wrote:
After kill -9 of the sync run it took about 20 minutes before it died.
I was seeing similar behaviour on one of our servers, and changing the io scheduler to noop fixed things for me. So it seems to be an issue with cfq which is somehow triggered by ext4 but not by ext3.
Quoted 5 lines
To change the IO scheduler, just execute
echo noop >
/sys/block/sda/queue/scheduler(replace sda if necessary).
Andre or Michael. If switching away from cfq helps, that's definitely... interesting. Given that cfq is the default scheduler, I definitely want to understand what might be going on here. Are either if you able to run blktrace so we can get a sense of what is going on under the cfq and deadline/noop I/O schedulers?
And in both of your cases, were you using a new file system freshly created using mke2fs -t ext4, or was this a ext2/ext3 filesystem that was converted for use under ext4?
Thanks,
- Ted
http://bugzilla.kernel.org/show_bug.cgi?id=14830
--- Comment #12 from Theodore Tso <[email protected]> 2010-01-28 09:18:21 ---
Quoted 8 lines · Andre Noll
Quoted 2 lines · On 11:19, [email protected] wrote:
After kill -9 of the sync run it took about 20 minutes before it died.
I was seeing similar behaviour on one of our servers, and changing the io scheduler to noop fixed things for me. So it seems to be an issue with cfq which is somehow triggered by ext4 but not by ext3.
Quoted 5 lines
To change the IO scheduler, just execute
echo noop >
/sys/block/sda/queue/scheduler(replace sda if necessary).
Andre or Michael. If switching away from cfq helps, that's definitely... interesting. Given that cfq is the default scheduler, I definitely want to understand what might be going on here. Are either if you able to run blktrace so we can get a sense of what is going on under the cfq and deadline/noop I/O schedulers?
And in both of your cases, were you using a new file system freshly created using mke2fs -t ext4, or was this a ext2/ext3 filesystem that was converted for use under ext4?
Thanks,
- Ted
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
Quoted 9 lines · Andreas Dilger
Quoted 8 lines · Andre Noll
Quoted 2 lines · On 11:19, [email protected] wrote:
After kill -9 of the sync run it took about 20 minutes before it died.
I was seeing similar behaviour on one of our servers, and changing the io scheduler to noop fixed things for me. So it seems to be an issue with cfq which is somehow triggered by ext4 but not by ext3.
Quoted 5 lines
Quoted 3 lines
To change the IO scheduler, just execute
echo noop >
/sys/block/sda/queue/schedulerAndre, could you please also test deadline instead of noop?
Sure. I just switched to deadline and the system still feels responsive while rsync is running. With cfq a simple "ls" command took ages to complete. I'll let you know if the system becomes sluggish again after a while.
Thanks
Andre
Signature · 1 line
The only person who always got his work done by Friday was Robinson Crusoe
Quoted 13 lines · On 02:53, [email protected] wrote:
Quoted 12 lines · Andre Noll
Quoted 2 lines · On 11:19, [email protected] wrote:
After kill -9 of the sync run it took about 20 minutes before it died.
I was seeing similar behaviour on one of our servers, and changing the io scheduler to noop fixed things for me. So it seems to be an issue with cfq which is somehow triggered by ext4 but not by ext3.
To change the IO scheduler, just execute
echo noop >
/sys/block/sda/queue/scheduler
Quoted 7 lines
Quoted 1 line
(replace sda if necessary).
Andre or Michael. If switching away from cfq helps, that's definitely... interesting. Given that cfq is the default scheduler, I definitely want to understand what might be going on here. Are either if you able to run blktrace so we can get a sense of what is going on under the cfq and deadline/noop I/O schedulers?
Yes, I can use that machine freely for testing purposes, including reboots. It is just our fallback server which creates hardlink-based snapshots using rsync.
However, I have to recompile the kernel to include debugfs which is needed by blktrace and I'd like to wait until the currently running rsync completes before rebooting. Would you like to see the output of
btrace /dev/mapper/...
or should I use more sophisticated command line options?
Quoted 3 lines
And in both of your cases, were you using a new file system freshly created using mke2fs -t ext4, or was this a ext2/ext3 filesystem that was converted for use under ext4?
The ext4 file system was created from scratch using -O dir_index,uninit_bg,extent, a block size of 4096 and 32768 bytes per inode.
Thanks
Andre
Signature · 1 line
The only person who always got his work done by Friday was Robinson Crusoe
http://bugzilla.kernel.org/show_bug.cgi?id=14830
--- Comment #13 from Anonymous Emailer <[email protected]> 2010-01-28 11:23:48 ---
Reply-To: [email protected]
Quoted 13 lines · On 02:53, [email protected] wrote:
Quoted 12 lines · Andre Noll
Quoted 2 lines · On 11:19, [email protected] wrote:
After kill -9 of the sync run it took about 20 minutes before it died.
I was seeing similar behaviour on one of our servers, and changing the io scheduler to noop fixed things for me. So it seems to be an issue with cfq which is somehow triggered by ext4 but not by ext3.
To change the IO scheduler, just execute
echo noop >
/sys/block/sda/queue/scheduler
Quoted 7 lines
Quoted 1 line
(replace sda if necessary).
Andre or Michael. If switching away from cfq helps, that's definitely... interesting. Given that cfq is the default scheduler, I definitely want to understand what might be going on here. Are either if you able to run blktrace so we can get a sense of what is going on under the cfq and deadline/noop I/O schedulers?
Yes, I can use that machine freely for testing purposes, including reboots. It is just our fallback server which creates hardlink-based snapshots using rsync.
However, I have to recompile the kernel to include debugfs which is needed by blktrace and I'd like to wait until the currently running rsync completes before rebooting. Would you like to see the output of
btrace /dev/mapper/...
or should I use more sophisticated command line options?
Quoted 3 lines
And in both of your cases, were you using a new file system freshly created using mke2fs -t ext4, or was this a ext2/ext3 filesystem that was converted for use under ext4?
The ext4 file system was created from scratch using -O dir_index,uninit_bg,extent, a block size of 4096 and 32768 bytes per inode.
Thanks
Andre
Signature · 6 lines
The only person who always got his work done by Friday was Robinson Crusoe -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
http://bugzilla.kernel.org/show_bug.cgi?id=14830
--- Comment #14 from Michael Godfrey <[email protected]> 2010-01-28 16:21:57 ---
Quoted 8 lines · On 01/27/2010 11:53 PM, [email protected] wrote:
And in both of your cases, were you using a new file system freshly created using mke2fs -t ext4, or was this a ext2/ext3 filesystem that was converted for use under ext4?
Thanks,
- Ted
In my case it is new ext4. I will try what tests I can in a day or two. The systems are busy right now.
Michael
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
http://bugzilla.kernel.org/show_bug.cgi?id=14830
--- Comment #15 from Theodore Tso <[email protected]> 2010-01-29 00:52:01 ---
Quoted 2 lines
In my case it is new ext4. I will try what tests I can in a day or two. The systems are busy right now.
Well, I'm flying back from New Zealand so I'll be off the grid mostly until Sunday or Monday.
Thanks for your efforts!
- Ted
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
http://bugzilla.kernel.org/show_bug.cgi?id=14830
--- Comment #16 from Michael Godfrey <[email protected]> 2010-01-29 06:37:55 --- I had a chance to try noop and deadline:
With the amount of testing that I could do they seemed to behave about the same, and:
1. the task timeouts are gone.
2. sync, which used to take over 20 minutes is consistently about 10 minutes. I did retest by setting scheduler back to cfg and the sync time went back to 24 minutes.
3. I also tried 2 variations:
1. rsync from source to target: rsync machinea:/aaa bbb
2. rsync of an NFS-mounted filesystem to local filesystem. (i.e the rsync thought it was local: rsync aaa/ bbb, but aaa was NFS-mounted (NFS3).
These two variation behaved just about identically.
I have left the system set to deadline, as recommended. With this setting (and with noop) things like du seem quicker too.
So, this is good, but 10 minutes for sync is still way too long. With these systems, I cannot compile debug kernels or stuff like that. They are in use for backup.
Any other suggestions?
Michael
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
http://bugzilla.kernel.org/show_bug.cgi?id=14830
--- Comment #17 from Michael Godfrey <[email protected]> 2010-02-04 04:16:40 --- I have now set deadline for all tests, and I had
a chance to try a system just like the one I have been
using, but with an 8.1T ext4 partition instead of the
11T partition before.
I used the same load: rsync /aaa /bbb, where /aaa was NFS-mounted.
The behavior was quite similar, but the longest sync time was about 4 minutes.
This suggests that the size of the filesystem is an important factor. Increasing the filesystem size by 36% more than doubled the sync time.
Th size of the database in the 2 systems was somewhat larger in the 11T system, but part of that was unused in the transfer.
Michael
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
http://bugzilla.kernel.org/show_bug.cgi?id=14830
--- Comment #18 from Jan Kara <[email protected]> 2010-02-15 14:28:38 --- Created an attachment (id=25050)
--> (http://bugzilla.kernel.org/attachment.cgi?id=25050)
Fix long sync times during heavy writing
Last week, I've noticed a bug in writeback code causing sync to take longer than necessary. This patch should fix it. Is it possible for you to try it? Thanks.
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
http://bugzilla.kernel.org/show_bug.cgi?id=14830
--- Comment #19 from Michael Godfrey <[email protected]> 2010-02-15 18:29:18 ---
Quoted 4 lines · On 02/15/2010 06:28 AM, [email protected] wrote:
Last week, I've noticed a bug in writeback code causing sync to take longer than necessary. This patch should fix it. Is it possible for you to try it? Thanks.
I have been following this. But right now I am leaving on a trip. And, I cannot right now build kernels for the system where we get the problem. These systems are in production use for backup.
Sorry that I cannot help more.
Michael
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
http://bugzilla.kernel.org/show_bug.cgi?id=14830
--- Comment #20 from Michael Godfrey <[email protected]> 2010-03-10 06:56:33 --- Created an attachment (id=25447)
--> (http://bugzilla.kernel.org/attachment.cgi?id=25447)
additional data from kernel 2.6.32.9-67.fc12.x86_64
Again, I have had very limited time, but I ran an rsync after update to kernel 2.6.32.9-67.fc12.x86_64.
The time for sync to complete was about as before, (about 10 minutes) and timeouts occurred as shown in the attached log entries.
I assume that the patches are not included in this kernel, but I just thought that I should report this test.
Michael
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
http://bugzilla.kernel.org/show_bug.cgi?id=14830
Eric Sandeen <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #21 from Eric Sandeen <[email protected]> 2010-03-10 15:36:20 --- Michael, you're right the patch is not in f12 (not in upstream yet, either).
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.