Hello Thibaut,

Quoting Thibaut VARENE:
: <[EMAIL PROTECTED]> wrote:
: > The update procedure should be something like:
: >
: >        rename /var/spool/uptimed/records as /var/spool/uptimed/records.old
: >        write new data to /var/spool/uptimed/records.new
: >        fsync()
: >        rename /var/spool/uptimed/records.new as /var/spool/uptimed/records
: >        unlink /var/spool/uptimed/records.old
: 
: It's pretty much what is done, save for the fsync():

Thanks for quoting the code.  But it's not really what it's doing:
It's writing to a uprecords.tmp and then renames that file to uprecords.
That's why there can be a dangling "uprecords" file that gets put in
lost+found once in a while...

My logic above first renames the old DB, writes a new record and only after
it has been renamed will the old file be unlinked.

: In my opinion, you don't want a process running fsync() every 60s,
: anyway. At least certainly not a subcritical process such as uptimed.

I concur. The fsync() is optional and not really needed on a journaling
filesystem.  Otherwise, fsync() is kind of needed to make sure the buffer
cache is flushed properly.  Naturally, as you noticed, the 60s is an
insane period for syncing! 600s should be the default (nobody will care
if the latest uptime misses 10 minutes!).  The DB should be flushed on
shutdown when uptimed exits anyway.

: Keeping the old records db as a fallback is an idea worth
: investigating, indeed. Cc'ing upstream maintainer.

What's important is that IF that .old file exists upon startup, then it means
something went wrong and therefore it should be used instead of the possibly
corrupted/missing uprecords file.

: > I'm flagging this bug as "important" because it is somehow defeating the
: > purpose of having a tool record uptimes if a sudden crash causes years of
: > history to get trashed.

: Agreed. What filesystem are you using on /var?

I use "ext2" there.  I should probably convert it to "ext3" but up to now,
I've kept using "ext2" on /, /usr and /var to make sure they are "fsck-ed"
every time if not unmounted cleanly.  I reserve "ext3" for "data partitions"
such as /home.  This decision was made a long time ago when ext3 was still
young.

Raphael



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to