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.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
