| Age | Commit message (Collapse) | Author |
|---|
|
When ovsdb-server reads a database file that is corrupted at the
transaction level (that is, the transaction is valid JSON and has the
correct SHA-1 hash, but it does not describe a valid database transaction),
then ovsdb-server should truncate it and overwrite it by valid
transactions. However, until now, it didn't. Instead, it would keep the
invalid transaction and possibly every transaction in the database file
(depending on in what way the transaction was invalid), which would just
cause the same trouble again the next time the database was read.
This fixes the problem. An invalid transaction will be deleted from the
database file at the first write to the database.
Bug #5144.
Bug #5149.
|
|
If there's database corruption then it indicates that something went wrong,
e.g. the machine was powered-off by power failure. It's definitely
something that the admin should know about. This sounds like an error to
me, so use that log level.
|
|
ovsdb_txn_commit() may return a ovsdb_error structure, which should be
freed by the caller. The only remaining caller that discards the result
is in ovsdb_file_open__(), which this fixes.
Suggested-by: Ben Pfaff <blp@nicira.com>
|
|
There's no indication that "date" is optional in the description of
ovsdb_file_txn_from_json(), and the one caller always passes it in, so
don't bother checking whether it exists.
Coverity #10732
|
|
Coverity #11066
|
|
This new function saves reading the whole database when only the schema is
of interest. This commit adapts ovsdb-tool to use it for the "db-version"
command. Upcoming commits will introduce another caller.
|
|
It's kind of odd for VLOG_DEFINE_THIS_MODULE to supply its own semicolon,
so this commit switches to the more common form.
|
|
These macros require one fewer argument by switching, which makes code
that uses them shorter and more readable.
|
|
Adding a macro to define the vlog module in use adds a level of
indirection, which makes it easier to change how the vlog module must be
defined. A followup commit needs to do that, so getting these widespread
changes out of the way first should make that commit easier to review.
|
|
Most of the timekeeping needs of OVS are simply to measure intervals,
which means that it is sensitive to changes in the clock. This commit
replaces the existing clocks with monotonic timers. An additional set
of wall clock timers are added and used in locations that need absolute
time.
Bug #1858
|
|
If the database grows fairly large, and we've written a fair number of
transactions to it, and it's been a while since the database was compacted,
then (after the next commit) compact the database.
Also, compact the database online if the "ovsdb-server/compact" command is
issued via unixctl. I suspect that this feature will rarely if ever be
used in practice, but it's easier to test than compacting automatically.
Bug #2391.
|
|
This is in preparation for exposing ovsdb_file to clients outside this
translation unit. These clients don't care that the ovsdb_file is an
ovsdb replica--that's an implementation detail--and so it makes sense to
rename it from their point of view.
This is just a search-and-replace plus reindenting where appropriate.
|
|
Found via inspection. I do not know that this fixes a real bug.
|
|
Until now, each part of a transaction commit that is interested in whether
a column's value has changed has had to do a comparison of the old and new
values itself. There can be several interested parties per commit
(generally one for file storage and one for each remove OVSDB connection),
so this seems like too much redundancy. This commit adds a bitmap
to struct ovsdb_txn_row that tracks whether a column's value has actually
changed, to reduce this overhead.
As a convenient side effect of doing these checks up front, it then
becomes easily possible to drop txn_rows (and txn_tables and entire txns)
that become no-ops. (This probably fixes bug #2400, which reported that
some no-ops actually report updates over monitors.)
|
|
Partial fix for bug #2391.
|
|
An upcoming commit will add another user for this code, so it is good to
abstract it a little better.
|
|
The current callers of ovsdb_log_open() always want to lock the file if
they are accessing it for read/write access. An upcoming commit will add
a new caller that does not fit this model (it wants to lock the file
across a wider region) and so the caller should be able to choose whether
to do locking. This commit adds that ability.
Also, get rid of the use of <fcntl.h> flags to choose the open mode, which
has always seemed somewhat crude and which this change would make even
cruder.
|
|
|
|
When a new record is inserted into a database, ovsdb logs the values of all
of the fields in the record. However, often new records have many columns
that contain default values. There is no need to log those values, so this
commit causes them to be omitted.
As a side effect, this also makes "ovsdb-tool show-log --more --more"
output easier to read, because record insertions print less noise. (Adding
--more --more to this command makes it print changes to database records.
The --more option will be introduced in an upcoming commit.)
|
|
The idea here is that transaction comments get copied to the ovsdb-server's
transaction log, which can then make it clear later why a particular change
was made to the database, to ease debugging.
|
|
An upcoming commit will add support for replicating tables across JSON-RPC
connection. As a prerequisite ovsdb itself must support basic replication.
This commit adds that support and then reimplements the ovsdb file storage
in terms of that replication.
|
|
This prepares for introducing a new, higher-level ovsdb_file that
encapsulates ovsdb storage in a file.
|
|
|
