On Tue, 6 Feb 2001, Matt Dillon wrote:
> :Reiserfs and ext3 have write-ahead logs and, AFAIK, fsync()
> :will not return until there is a commit point in the log.
> :
> :This means that fsync() will guarantee that the transactions
> :won't be unwound (unless I've overlooked some weird special
> :case situations where it is needed after all...).
>
> Yes, I believe you are correct. I was operating under the impression
> that ReiserFS had only one log, though. I have not researched EXT3
> so I can't comment on it. So if you fsync() a file under Reiser, aren't
> you fsync()ing the entire filesystem?
It would only need to do 2 things:
1. put a sync point in the journal, after writing all the
needed data to the journal (cheap, no disk seeks involved)
2. write out the file data to the filesystem
For ext3, you can either go the same way as reiserfs or you
can do full data journalling. With full data journalling you
will end up writing the data twice, but you can return from
fsync() after having synced the data to the journal only...
This decrease in latency means that for some workloads doing
full data journalling could give better performance than
metadata-only journalling.
And then, of course, there's the option of moving the journal
to a separate device. In this situation doing data journalling
will almost certainly improve performance if your workload has
lots of fsyncs sincy you both cut down on the seek times needed
for an fsync and the "real filesystem" has more freedom to
reorder the writes it does ... the data has everything needed
for the last few seconds, so why worry.
regards,
Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
