* Xu Yifeng <jamexu@telekbird.com.cn> [010316 01:15] wrote:
> Hello Alfred,
>
> Friday, March 16, 2001, 3:21:09 PM, you wrote:
>
> AP> * Xu Yifeng <jamexu@telekbird.com.cn> [010315 22:25] wrote:
> >>
> >> Could anyone consider fork a syncer process to sync data to disk ?
> >> build a shared sync queue, when a daemon process want to do sync after
> >> write() is called, just put a sync request to the queue. this can release
> >> process from blocked on writing as soon as possible. multipile sync
> >> request for one file can be merged when the request is been inserting to
> >> the queue.
>
> AP> I suggested this about a year ago. :)
>
> AP> The problem is that you need that process to potentially open and close
> AP> many files over and over.
>
> AP> I still think it's somewhat of a good idea.
>
> I am not a DBMS guru.
Hah, same here. :)
> couldn't the syncer process cache opened files? is there any problem I
> didn't consider ?
1) IPC latency, the amount of time it takes to call fsync will increase by at least two context switches.
2) a working set (number of files needed to be fsync'd) that is larger than the amount of files you wish to keep
open.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]