> Could you repost these results compared to the run time from > Dominic's BFS for the same test? This would give an indicator as to how far you still have to go. Keep up the great work. That's currently not possible - at least not for this test, as it was done using the userland fs shell, and this test is not available for BFS (and it also was done with profiling turned on). Some numbers for another test (copy 434 files to the disk (1.8 MB)) [current code, not yet in CVS]: our BFS with a max. of 123 blocks per log entry: 30s (13.8s transaction, 16.18s sync) our BFS with a max. of 252 blocks per log entry: 26s (6.5s transaction, 19.8s sync) our BFS with a max. of 506 blocks per log entry: 24s (4.5s transaction, 19.6s sync) our BFS with a max. of 1018 blocks per log entry: 26s (0.3s transaction, 25.7s sync) original: 23s (2.3s transaction, 20.8s sync) To copy these files, there were 7745 transactions with more than 13000 affected blocks, which caused our BFS to write 9 log entries (for the case with a max. of 123 blocks per log entry). In the case with 1018 blocks per log entry, all transactions fit completely into one log entry which means that it's done entirely in the cache - which explains why the sync takes that long. For this test our BFS comes very close to the original one with a maximum of 506 blocks per log entry. BTW 506 blocks mean that any new transaction will be added to the current log if that size is not more than 506 blocks - so the whole log entry can contain even more blocks. Adios... Axel.