Hi, The slow sync problems still exist with fresh vanilla kernel patched with Reiser4 only (reiser4-for-2.6.14-1.patch). The slow sync occurs regardless of which IO scheduler is in use.
[EMAIL PROTECTED]:~$ uname -a Linux teratron.lan.etheus.net 2.6.14.2 #2 PREEMPT Tue Nov 22 23:48:39 GMT 2005 i686 GNU/Linux See the attached testscript.sh These are the results from the script: sync a1 real 0m1.301s user 0m0.000s sys 0m0.000s sync a2 real 0m0.341s user 0m0.004s sys 0m0.000s sync a3 real 0m0.341s user 0m0.004s sys 0m0.004s sync a4 real 0m0.307s user 0m0.000s sys 0m0.000s Performing recursive ls real 0m0.307s user 0m0.080s sys 0m0.220s sync b1 real 0m9.716s user 0m0.000s sys 0m0.024s sync b2 real 0m0.391s user 0m0.004s sys 0m0.000s sync b3 real 0m0.316s user 0m0.000s sys 0m0.000s sync b4 real 0m0.341s user 0m0.000s sys 0m0.000s Performing recursive ls real 0m0.734s user 0m0.216s sys 0m0.516s sync c1 real 0m53.698s user 0m0.000s sys 0m0.108s sync c2 real 0m0.665s user 0m0.000s sys 0m0.004s sync c3 real 0m0.125s user 0m0.000s sys 0m0.008s sync c4 real 0m0.125s user 0m0.000s sys 0m0.000s Sync a1->a4 execute relatively quickly The recursive ls happen very quickly because the data is already cached. Syncs immediately after the recursive ls take ages. This is really strange since the recursive ls does not touch the disk because the data is cached. My guess is that when sync is called, the cache of ALL recently accessed data is either being committed back to disk, or being re-read. -- Craig Shelley EMail: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED]
testscript.sh
Description: application/shellscript
signature.asc
Description: This is a digitally signed message part
