https://bugzilla.novell.com/show_bug.cgi?id=371575 User cmorve69@yahoo.es added comment https://bugzilla.novell.com/show_bug.cgi?id=371575#c1 --- Comment #1 from Christian Morales Vega 2008-03-16 13:27:40 MST --- Created an attachment (id=202352) --> (https://bugzilla.novell.com/attachment.cgi?id=202352) lspci -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=371575 Jeff Mahoney changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|kernel-maintainers@forge.provo.novell.com |teheo@novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=371575 User cmorve69@yahoo.es added comment https://bugzilla.novell.com/show_bug.cgi?id=371575#c4 Christian Morales Vega changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|cmorve69@yahoo.es | --- Comment #4 from Christian Morales Vega 2008-03-29 04:35:17 MST --- $ head -n1 /etc/mtab /dev/sda6 / ext3 rw,noatime,acl,user_xattr,barrier=0 0 0 $ cat /sys/block/sda/queue/scheduler noop anticipatory [deadline] cfq Same behaviour, 50% wait CPU usage in top. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=371575 User cmorve69@yahoo.es added comment https://bugzilla.novell.com/show_bug.cgi?id=371575#c6 Christian Morales Vega changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED Info Provider|cmorve69@yahoo.es | Resolution| |INVALID --- Comment #6 from Christian Morales Vega 2008-03-29 12:58:07 MST --- If first noted the problem when trying to burn a data DVD and the buffer was emptying constantly. I saw a high wait CPU usage and I though that was the problem. Since the burn worked fine (and 4-5 times faster) from the PATA drive I saw a problem... But now I'm unable to reproduce this trying to write a data CD. Neither in the 32bits or 64bits openSUSE. I don't know, perhaps is because the SATA drive was nearly full the first time and now I have freed 50GB. The lower responsiviness while writing files between hard drives, I don't know, could be a problem or just something normal. Isn't so bad... So since the 100% wait CPU usage is something normal and I can't reproduce the problems burning I close the bug. If I see the burning problem again I will try to find a way to reproduce it and I would reopen the bug. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=371575 User cmorve69@yahoo.es added comment https://bugzilla.novell.com/show_bug.cgi?id=371575#c8 --- Comment #8 from Christian Morales Vega 2008-03-30 02:56:21 MST --- I did, but saw no difference. Both cases gave results that... well, 7MB/s when the hard drive is supposed to be >100MB/s? But I don't know up to what point that's normal for big files on ext3. I just tried copying files. Perhaps not the best test, but... which one? Also copying a 400MB file was a lot faster than a 1,4GB file (a lot faster than 1400/400). So in such a test the filesystem also plays a role that "contaminates" the results. I also tried writing files with "time yes | head -c $((200*1024*1024)) > output" without differences between i386 and x86-64. So was when I retested burning in x86-64 and saw that this time everything worked fine. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=371575 User cmorve69@yahoo.es added comment https://bugzilla.novell.com/show_bug.cgi?id=371575#c10 --- Comment #10 from Christian Morales Vega 2008-04-06 05:10:49 MST --- With 700MiB files. - On x86-64 The first times with a file give ~8-9MB/s Repeated times with the same file go up to 650MB/s - On x86 The first times with a file give ~8-9MB/s Repeated times with the same file go up to 375MB/s -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=371575 User cmorve69@yahoo.es added comment https://bugzilla.novell.com/show_bug.cgi?id=371575#c12 Christian Morales Vega changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cmorve69@yahoo.es --- Comment #12 from Christian Morales Vega 2008-04-07 08:01:11 MST --- With the new options it goes up to 13MB/s. I tried with three files and all of them gave the same results. But now that I have plenty of free space I have make a copy of one of these files, expecting the new one to be less fragmented, and the 8-9MB/s-13MB/s go up to 60MB/s. I don't know if it's normal a x6 penalty because of fragmentation. The PATA drive, with very little free space give me +50MB/s results with both old files and others created right now. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=371575 User jack@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=371575#c14 --- Comment #14 from Jan Kara 2008-04-07 13:45:05 MST --- The command "dd if=somelargefile of=/dev/null" could have been slowed down by the fact that dd read one-byte-at-time and the syscall overhead is really noticable there. I think part of the difference between 8-9MB/s and 13MB/s could be due to this fact. Anyway can you run (as root): filefrag the-slow-file That will tell us how many fragments are there in the file. A rough computation shows that if the file has ~10000 fragments (i.e., 71 KB per fragment) the seeks would cause the speed difference between 9MB/s and 60MB/s... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.