Re: flush on close

2003-09-12 Thread Clifton Royston
> Date: Fri, 12 Sep 2003 05:38:12 +1000 (EST) > From: Bruce Evans <[EMAIL PROTECTED]> > Subject: Re: flush on close > To: Eno Thereska <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: TEXT/PLAIN; charset=US-ASCII

Re: flush on close

2003-09-11 Thread Bruce Evans
y though. I have a suspicion that BSD is using the > "flush-on-close" semantic. > > Could someone confirm or reject this claim? > If confirmed, I am wondering how to get rid of it... ffs_fsync() is (or should be) rarely called except as a result of applications calling fsync(2)

Re: flush on close

2003-09-11 Thread Eno Thereska
-close semantics is an orthogonal issue. For example, with the async option, with the flush-on-close semantics, data and metadata are flushed. Please let me know if you have any more hints on this. Thanks Eno On Thu, 11 Sep 2003, Doug White wrote: > Remove -fs. Don't crosspost, please

Re: flush on close

2003-09-11 Thread Doug White
Remove -fs. Don't crosspost, please. On Wed, 10 Sep 2003, Eno Thereska wrote: > In FreeBSD 4.4, I am noticing a huge number of calls > to ffs_fsync() (in /sys/ufs/ffs/ffs_vnops.c) > when running a benchmark like Postmark. Were you using softupdates, or the sync or async mount options? I believe

flush on close

2003-09-10 Thread Eno Thereska
the file, or if the syncer daemon or buffer daemon decide it's time for the dirty blocks to go to disk. Neither of these two options is happening. Files are opened and closed very frequently though. I have a suspicion that BSD is using the "flush-on-close" semantic. Could som