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. > 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? >
