Right.
>... could you turn on kernel profiling and send the top few functions
>while this is running. Unless it is doing a lot of I/O the 100 seconds
>still seems way long... (hmm. 1.4G/512= ~2.8M... 2.8 million buffer
>lookups... ouch) Is that file full of holes? or is it completely full
>of data?
I'll make a profiling run tomorrow, unless someone posts a solution
before then. The file shouldn't have any holes. Yes, it has 1.4 GB
worth of data. I can see why 2.8 million buffer lookups would take
time...
>If you have access to the source try changing the way it does things.
>you can:
> 1) use O_SYNC on the file, which does what you need.
> 2) use sync() to sync the entire disk... which will mostly
> do what you want, but on busy systems will do a whole lot
> more... since it checks buffers in memory, it may actually
> take quite a lot less time...
>
>anybody else have better ideas... (flame me if I'm totally off base)
I don't have the source (it's a commercial database server). I'm
really tempted to map all of the fsync() calls to sync() -- I can't
see how that could slow me down much, since the database is the only
noteworthy process on this system.
What's the easiest way to force a sync? LD_PRELOAD a libc with
fsync() munged? Or should I just drop fsync clean out of ext2? It'll
fall back to sync, right? Would this work?
--- file.c-old Thu Oct 2 17:54:01 1997
+++ file.c Thu Oct 2 17:54:15 1997
@@ -54,7 +54,7 @@
generic_file_mmap, /* mmap */
NULL, /* no special open is needed */
ext2_release_file, /* release */
- ext2_sync_file, /* fsync */
+ NULL, /* fsync */
NULL, /* fasync */
NULL, /* check_media_change */
NULL /* revalidate */
Like I said, the only important process on this system is the database
server.
Scott