Jerome Vouillon <vouillon@saul.cis.upenn.edu> writes:
> Actually, there is also a performance reason. Indeed, fdatasync would
> not perform any better than fsync if the log file was not
> preallocated: the file length would change each time a record is
> appended, and therefore the inode would have to be updated.
Good point, but seeking to the 16-meg position and writing one byte was
already sufficient to take care of that issue.
I think that there may be a performance advantage to pre-filling the
logfile even so, assuming that file allocation info is stored in a
Berkeley/McKusik-like fashion (note: I have no idea what ext2 or
reiserfs actually do). Namely, we'll only sync the file's indirect
blocks once, in the fsync() at the end of XLogFileInit. A correct
fdatasync implementation would have to sync the last indirect block each
time a new filesystem block is added to the logfile, so it would end up
doing a lot of seeks for that purpose even if it rarely touches the
inode itself. Another point is that if the logfile is pre-filled over a
short interval, its blocks are more likely to be allocated close to each
other than if it grows to full size over a longer interval. Not much
point in avoiding seeks outside the file data if the file data itself
is scattered all over the place :-(.
Basically we're trading more work in XLogFileInit (which we hope is not
time-critical) for less work in typical transaction commits.
regards, tom lane
