xfs
[Top] [All Lists]

Re: Power loss and zero-length files

To: Robert Widmer <robertwidmer@xxxxxxxxx>
Subject: Re: Power loss and zero-length files
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Sat, 24 Aug 2013 04:15:09 -0700
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <CAGwuE-p8=UwpGUhgpqkWn4U4jU-KnfC3C19Kqqv7uYLJvubxgQ@xxxxxxxxxxxxxx>
References: <CAGwuE-p8=UwpGUhgpqkWn4U4jU-KnfC3C19Kqqv7uYLJvubxgQ@xxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Fri, Aug 23, 2013 at 10:59:50AM -0400, Robert Widmer wrote:
> 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.

>From looking at the scripts this looks expected.

> 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;
>     }
> }

there is nothing flushing out the data to disk, so if the xfs metadata
commit interval is faster than the the VM dirty writeback time the above
is what you get.  Try doing the perl exquivalent of a fsync/fdatasync on
the OUT fd and things should be on disk.

> 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

What kind of disk is this?  You said VM above, so I'd be curious what
kind of VM doesn't support the scsi caching mode pages.

<Prev in Thread] Current Thread [Next in Thread>