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 -
#!/usr/bin/perl
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 -
sync:
real 0m0.048s
user 0m0.000s
sys 0m0.046s
dd:
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
fsync_test.pl:
real 0m10.237s
user 0m0.012s
sys 0m0.133s
sync:
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
'time'ing.
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.
--
Matthias
|