463394 - Profile destroyed on nfs mounted homedir, if client OS experiences e.g. a power outage

Status: RESOLVED INCOMPLETE

(Firefox :: General, defect)

Description

[Erik Hensema]

When firefox runs off a nfs mounted homedirectory which is async mounted (as are most nfs shares due to performance reasons), the profile is destroyed on a client crash such as a power loss, kernel panic, reset button pressed, etc.

The problem manifests itself in two clear symptoms: all bookmarks are destroyed, and firefox always wants to restore a running session, even after a subsequent successful quit.

The problem is probably caused by the async mount: the nfs server is permitted to lie to the nfs client on completed writes. Because this greatly improves performance (actually sync mounts are not usable, they're THAT slow), sync mounts are the common case on nfs.

The problemen can probably be easily solved by passing the O_SYNC flag on critical file open()s, such as the sqlite databases. This forces the nfs server to perform synchronous operations on specified files, making atomic operations really atomic again, which is cricital to the reliability of database transactions.

Comment 1

[timeless]

we use fsync(fd);

is that not guaranteed to work?

http://nfs.sourceforge.net/
Version 3 clients use COMMIT operations when flushing safe asynchronous writes to the server during a close(2) or fsync(2) system call, or when encountering memory pressure. 

Since Linux 2.4, the NFS Version 3 server recognizes the "async" export option. When this option is set, the server replies to clients before data has been written to permanent storage. The server also sends a FILE_SYNC response to the client, indicating that the client need not retain buffered data or send a subsequent COMMIT operation. 

my understanding is that this is the path we take. please find a nice document that explains why this isn't acceptable.

http://mxr.mozilla.org/mozilla-central/source/db/sqlite3/src/sqlite3.c?mark=22854,22873,22792,22831#22781

Comment 2

[Timea Cernea [:tbabos][inactive]]

There are no updates for this issue in the last 13 years, seems to be outdated. Erik, could you please follow-up on this one or at least let us know if this is still relevant? If not, it should be closed. Thanks!

Comment 3

[Erik Hensema]

Please just close 13 year old bugs. It's stupid to keep them unresolved for this long.