On Wed, May 11, 2011 at 9:28 PM, Martin Steigerwald <mar...@lichtvoll.de> wrote: > the fsync() based approach - when it works - would give the following > advantage: either the new records or the old records file is there. Thus at > maximum one interval of uptime is lost. With checking sanity of > configuration file everything since the last backup from uptimed is lost, > which might be days, *weeks or more.. > > An idea comes to my mind: How about saving the *current* record in an own > file in the same format, one line, thats no more than a sector. Either this > thing is on disk or the old one is still there, fsync() or not.
By which logic do you come to that conclusion? You seem to be gravely mistaken about how the VFS works. Also, did you notice that a 50-entry record file is generally under 4KB, typical filesystem block size? > Then when uptimed starts up from a fresh boot it generated a new bootid > and integrated the old one into the records file. uprecords would be > changed to read both "records" and "current-record", merging them. Bootid is not used on BSD. > This also makes saving records an O(1) operation. No matter how many > records are stored in the records file, the current-records file just holds > the current record. Wow, now that's a performance improvement. We're talking dumping less than 5KB to disk... Other than that I give you some credit: I do believe that such a scheme would indeed only lose the "current/last" uprecord entry upon crash. Except it still doesn't fix the issue which you seem to be really unhappy about, which is uptimed not being able to track uptimes after crash (which is a feature, afai'm concerned), and it will probably quite complicate the whole thing. And oh, what's happening to people running new (per your design) uptimed with old database, and/or re-running old uptimed with new database? The patch I proposed should most likely fix 99.9% of the issues you're complaining about, while remaining 100% compatible with the current behavior. Finally, if you want to propose a design change and/or a patch, I suggest CCing or writing directly to upstream, as I am *not* uptimed's developer. -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
