Clay Barnes wrote: >On 18:38 Tue 06 Jun , Vladimir V. Saveliev wrote: > > >>Hello >> >>On Tue, 2006-06-06 at 09:44 -0400, Tom Vier wrote: >> >> >>>On Tue, May 23, 2006 at 11:51:02AM -0400, Tom Vier wrote: >>> >>> >>>>It seems that both r4 and xfs allow a large number of pages to be dirtied, >>>>before queuing them for writeback, and this has a negative effect on >>>>throughput. In my test (rsync'ing ~50gigs of flacs), r4 and xfs are almost >>>>10 minutes slower than jfs. >>>> >>>> >>>Just to follow up on this (i've been too busy lately), that's how delayed >>>allocation works. It waits til the vm forces writeouts. >>> >>>In my case of copying large files from a slower drive, the delayed allocation >>>of r4 and xfs is stalling reads from the source, since neither will write >>>until the vw forces it. >>> >>>Is there a way in r4 to force sync a mount every so often, ala flushd? >>> >>> >>reiser4 has an option for that. >>mount -o tmgr.atom_max_age=N >>N is decimal number of seconds. Changes older than N will be forced to >>commit. >> >> >This may have been mentioned before, but perhaps there could be a >"trickle-out" option along the lines of "if the hard drive is idle (and >optionally only if it's spun up), slowly write out the changes to the >disk structure." > Yes, I will take a patch to do the above as it would be good, but I am not convinced it explains the problem described. I don't really understand how writes to a fast drive can slow reads from a slow drive. I am missing something.
Maybe I should ask the following: is the slow drive using reiser4? If reiser4, was the slow drive image created by copying from a reiser4 image or an ext3 image? (Standard benchmarking mistake: creating an image for a test from a filesystem not the one that is being tested. readdir order matters.) > This could also be paired with keeping as much of the >data in memory as necessary to mantain the speed boost that r4 gets from >temporal locality of reference, possibly just giving it to the system >cache. > > >>>ext3 >>>has the commit option. Does r4 have a hard coded sync timer already? If not, >>>i think it's an important feature that should be added (and made a mount >>>option). Otherwise, a lot of data can be lost. Does the kernel do a system >>>wide sync every 30sec, like it used to? >>> >>> >>> > > > >
