On Tue, Jan 18, 2011 at 8:28 AM, Laurent Bonnaud
<[email protected]> wrote:
> Hi,
>
> I also experienced this bug several times on a laptop that sometimes
> fails to resume from suspend and with an ext4 filesystem.
>
> Here is a patch that should fix the problem:
>
> --- urec.c~ 2009-01-02 00:46:00.000000000 +0100
> +++ urec.c 2011-01-18 08:07:28.886203152 +0100
> @@ -263,6 +263,7 @@
> if ((max > 0) && (++i >= max)) break;
> }
> }
> + fflush(f);
> fclose(f);
> rename(FILE_RECORDS, FILE_RECORDS".old");
> rename(FILE_RECORDS".tmp", FILE_RECORDS);
DESCRIPTION
The fclose() function flushes the stream pointed to by fp (writing any
buffered output data using fflush(3)) and closes the underlying file
descriptor.
For the records, as it's been explained before (
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536823#29 ) what's
needed here to definitely "fix" this problem is added logic which
would check upon opening the database that it's not empty, and if it
is, that would discard it and use the backup one.
For what it's worth, this "behaviour" is expected: when fclose() is
hit, the data may still reside in the VFS cache. On journaled
filesystem, under the most usual setups, only the metadata may be
actually flushed. When a crash occurs, the journal will restore
filesystem consistency by either removing (case covered by the use of
the backup file) or zero-out (XFS will typically do that) files which
are in an inconsistent state with the journal.
The only way to prevent this would be to add a fsync() before every
fclose(), which would force sync the data to disk. But then, I suggest
reading the fsync(2) manpage to understand the implications in terms
of performance impact and constant wakeup of harddrives for users who
spin down their drives, overall impact which would be totally
unacceptable for a "bug" that's caused by a "non normal" operation of
the software. (NB: no, a crash or a power loss is not "normal" use of
the system).
It's a common misconception that people believe filesystems, and
especially journaled ones, should be crash-proof. They're not.
HTH
T-Bone
--
Thibaut VARENE
http://www.parisc-linux.org/~varenet/
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
