Hi guys,
----- Original Message -----
> ...
>
> Providing data integrity is not as simple as you're thinking, also.
> fsync(2) alone is not enough to provide the guarantee you seek.
Have just come across commit 5a3a2494 in fche/dev, and it seems
I was too late sending this mail as the following has already
been attempted. If only the missing QA for pmmgr was tackled so
vigorously! ;) -- I would be so happy.
Anyhow...
[ git://sourceware.org/git/pcpfans.git fche/dev ]
$ git show 5a3a249497cc3e3a93495fa77b41559e8b706ab4 | diffstat
include/pcp/impl.h | 12 ++++++++++++
libpcp/src/logutil.c | 11 ++++++-----
libpcp_import/src/archive.c | 4 ++++
pmlogextract/pmlogextract.c | 5 ++++-
pmlogger/src/pmlogger.c | 12 ++++++++++--
pmloglabel/pmloglabel.c | 8 ++++----
pmlogreduce/logio.c | 2 +-
pmlogreduce/pmlogreduce.c | 4 ++++
pmlogrewrite/pmlogrewrite.c | 8 ++++++--
9 files changed, 51 insertions(+), 15 deletions(-)
["logging durability: add fsync(2) when closing log archives"]
Can you describe the testing done for this change or planned?
Also, thoughts on the impact the newly introduced latency will
have on these code paths and the tools/scripts using them? (I
haven't thought it through, so keen to hear thoughts - or any
observations/measurements so far)
If anyone has not come across it before, I'd highly recommend
an article Valerie Aurora wrote discussing fsync/rename here:
http://lwn.net/Articles/351422/
Note also the mentions she makes of performance implications,
important for us folks attempting to minimise our impact on
the observed system. There's also other subtleties discussed
on the fsync(1) man page, its well worth a careful read too -
the directory paragraph is relevant to our needs.
OK, enough for this week - will chat later.
cheers.
--
Nathan
|