[Top] [All Lists]

Re: Questions about XFS

To: Steve Bergman <sbergman27@xxxxxxxxx>
Subject: Re: Questions about XFS
From: Matthias Schniedermeyer <ms@xxxxxxx>
Date: Tue, 11 Jun 2013 23:57:16 +0200
Cc: linux-xfs@xxxxxxxxxxx
Delivered-to: linux-xfs@xxxxxxxxxxx
In-reply-to: <CAO9HMNEt4XKdV6+jfKwHVPrDaVNytx65MQDK52Uckcy-O6YikQ@xxxxxxxxxxxxxx>
References: <loom.20130611T112155-970@xxxxxxxxxxxxxx> <20130611193525.GT20932@xxxxxxx> <CAO9HMNEt4XKdV6+jfKwHVPrDaVNytx65MQDK52Uckcy-O6YikQ@xxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On 11.06.2013 14:55, Steve Bergman wrote:
> Hi Ben,
> /usr/local/data - Ext3 (Cobol doesn't know about fsync. I need
> pony-magic in this LV.)

You COULD do a little magic external of the program to expedite writing 
to stable storage.

- fsync_test.pl -

use File::Sync qw(fsync);

open my $fh, '<', 'testfile' or die ("Can't open: $!");
fsync($fh) or die ("Can't fsync: $!");
close $fh;
- fsync_test.pl -

- fsync_test.sh -
rm -f testfile
echo -n sync: ; time sync
echo ; echo -n dd: ; time dd if=/dev/zero of=testfile bs=1M count=1k
echo ; echo -n fsync_test.pl: ; time ./fsync_test.pl
echo ; echo -n sync: ; time sync
- fsync_test.sh -

The result on my machine against a HDD:

- result -
real    0m0.048s
user    0m0.000s
sys     0m0.046s

1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.317354 s, 3.4 GB/s
real    0m0.318s
user    0m0.001s
sys     0m0.316s

real    0m10.237s
user    0m0.012s
sys     0m0.133s

real    0m0.047s
user    0m0.000s
sys     0m0.045s
- result -

This tells me that a program can fsync a file i didn't write itself.

I choose 1GB because it can be created fast enough to not trigger any 
automatic writebacks (And with 32GB of RAM it is well within default 
limits) and still long enough to be easily visible with simple 

With secret ingredient number 2, inotify, you COULD write a program that 
does 'fsync'(s) after the program that can't do it itself. Of course 
that can only expedite matters, it doesn't give you the same consistency 
guarantees as the original program isn't the one waiting for the 
fsync(s) to complete and happily continues dirtying more data in the 
mean time. 

And there also is syncfs which is relativly new (man-page says it was 
introduced with kernel 2.6.39). 'syncfs' is a lighter version of 'sync' 
that only syncs a single filesystem. So you could make a program that 
does a syncfs every second or so (with the help of inotify you could do 
it after something "interesting" was written), without impacting other 
filesystems like 'sync' does.



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