martin f krafft <madduck@xxxxxxxxxxx> writes:
[Sorry but that was really explained multiple times. Read the archives again
for more details. Here just quick explanation.]
> From what I understand, binary zeroes appear to replace file
> contents after a system crash. The FAQ says that this is because the
> file has been allocated, but the system had no time to write, so it
> was empty. What surprises me here is that XFS nulls the file.
> Normally, a newly allocated file is garbage to be overwritten, not
> one zero after the other. Or are the zeroes overlaid on read() when
> the inode is inconsistent?
The new file size (=metadata) has been already flushed to disk, but
the actual data hasn't yet. Missing data is a "hole" which reads as all
zeros. If the system crashes in this window you see the hole.
The main reason for this is that the flush delay for file data is much
longer (minutes) compared to meta data like file size. Due to
the way the XFS log works metadata tends to be flush very often.
So you often have the updated metadata on disk, but no matching
file data yet.
There are various tunables in /prov/sys/vm to make file data be flushed
faster (in 2.6 currently /proc/sys/vm/dirty_expire_centisecs, the
names of these unfortunately change quite often).
You can change that if you want, but in general making it to be flushed
as often as the metadata would ruin performance.
Of course you can sync any time manually with sync(1) or fsync(2)/fdatasync(2)
in a program.