<div dir="ltr">I had a script that updated several files on an XFS filesystem using "sed -i", and someone decided to power cycle the box without a sync after running the script, and found that all the files that were updated were now zero-length.<div>
<br></div><div>Curious, I ran the following script to try and isolate the behavior:</div><div><br></div><div><div><br></div><div><div>#!/usr/bin/perl</div><div><br></div><div>my $dir = "/home/$ENV{USER}/XFSTest";</div>
<div>mkdir $dir;</div><div>chdir $dir;</div><div><br></div><div>my $filecount = 100;</div><div>my $tmpfile = 'file.tmp';</div><div><br></div><div>while (1) {</div><div>    for (my $i=0; $i<$filecount; $i++) {</div>
<div><span class="" style="white-space:pre">    </span>my $filename = "file.$i";</div><div><span class="" style="white-space:pre">        </span>open(OUT, ">", $tmpfile);</div><div>        print OUT "Time:".localtime."\n";</div>
<div>        close OUT;</div><div><span class="" style="white-space:pre">   </span>rename $tmpfile, $filename;</div><div>    }</div><div>}</div></div></div><div><br></div><div><br></div><div>On the following release/kernels in a VM:</div>
<div><br></div><div>Fedora 16 w/kernel 3.1.0-7.fc16.x86_64</div><div>Fedora 16 w/kernel 3.6.11-4.fc16.x86_64</div><div>Fedora 19 w/kernel 3.10-7.200.fc19.x86_64</div><div>Ubuntu 13.04 w/kernel 3.8.0-19-generic</div><div><br>
</div><div><br></div><div>And after a power cycle, all the files are zero-length with no extents.</div><div><br></div><div>(CentOS 6.4 w/kernel 2.6.32-358.14.1.el6.centos.plus.x86_64 has the binary NULLS)</div><div><br></div>
<div>Barriers are not disabled and drive cache:</div><div>[    2.145011] sd 2:0:0:0: [sda] Cache data unavailable<br></div><div><div>[    2.145013] sd 2:0:0:0: [sda] Assuming drive cache: write through</div></div><div><br>
</div><div><br></div><div>The closest thing I can find in the documentation is the XFS FAQ which mentions "<span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px;line-height:19.046875px">you are looking at an inode which was flushed out, but whose data was not</span>", which seems to indicate that the inode writes and data writes are not done in order, but nothing explicitly documents this.</div>
<div><br></div><div>Is this expected behavior?</div><div><br></div><div>I've added a sync to the end of my script to try and ensure this does not happen again, and losing some amount of data after a power loss is expected, but it seems counter-intuitive that the inode/data writes are not done in order and that rapid file changes can result in such a large number of files being zero-length.</div>
<div><br></div></div>