Pierre-Frédéric Caillaud wrote:
22 KB files, 1000 of them :
open(), read(), close() : 10.000 files/s
open(), write(), close() : 4.000 files/s
This is quite far from database FS activity, but it's still
amazing, although the disk doesn't even get used. Which is what I like
in
Another possibly useless datapoint on this thread for anyone who's
curious ... open_sync absolutely stinks over NFS at least on Linux. :)
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
The world rejoiced as [EMAIL PROTECTED] (Merlin Moncure) wrote:
Ok, you were right. I made some tests and NTFS is just not very
good in the general case. I've seen some benchmarks for Reiser4
that are just amazing.
Reiser4 has been sounding real interesting.
The killer problem is thus:
Greetings,
I have observed that in a dump/restore scenario the longest time is
spent on index creation for larger tables, I have a suggestion of how
the performance could be improved thus reducing the time to recover
from a crash. Not sure if this is possible but would definitely be a
nice
On Sat, 2004-09-04 at 23:47 -0400, Christopher Browne wrote:
The world rejoiced as [EMAIL PROTECTED] (Merlin Moncure) wrote:
Ok, you were right. I made some tests and NTFS is just not very
good in the general case. I've seen some benchmarks for Reiser4
that are just amazing.
Reiser4
