Power loss and zero-length files

[Robert Widmer]

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.

Curious, I ran the following script to try and isolate the behavior:


#!/usr/bin/perl

my $dir = "/home/$ENV{USER}/XFSTest";
mkdir $dir;
chdir $dir;

my $filecount = 100;
my $tmpfile = 'file.tmp';

while (1) {
    for (my $i=0; $i<$filecount; $i++) {
my $filename = "file.$i";
open(OUT, ">", $tmpfile);
        print OUT "Time:".localtime."\n";
        close OUT;
rename $tmpfile, $filename;
    }
}


On the following release/kernels in a VM:

Fedora 16 w/kernel 3.1.0-7.fc16.x86_64
Fedora 16 w/kernel 3.6.11-4.fc16.x86_64
Fedora 19 w/kernel 3.10-7.200.fc19.x86_64
Ubuntu 13.04 w/kernel 3.8.0-19-generic


And after a power cycle, all the files are zero-length with no extents.

(CentOS 6.4 w/kernel 2.6.32-358.14.1.el6.centos.plus.x86_64 has the binary
NULLS)

Barriers are not disabled and drive cache:
[    2.145011] sd 2:0:0:0: [sda] Cache data unavailable
[    2.145013] sd 2:0:0:0: [sda] Assuming drive cache: write through


The closest thing I can find in the documentation is the XFS FAQ which
mentions "you are looking at an inode which was flushed out, but whose data
was not", which seems to indicate that the inode writes and data writes are
not done in order, but nothing explicitly documents this.

Is this expected behavior?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20130823/8e90cc23/attachment.html>