ecryptfs team mailing list archive

[Tom Jaeger <ThJaeger@xxxxxxxxx>]

It's easy to lay the blame on "crappy" applications, but the fact of the
matter is that it is really the interface that sucks here.  Using the
notation of comment #54, what applications really want is execute (1)
atomically.  Then it shouldn't matter whether they rewrite their files
every minute or every second, because the file system could still decide
when to actually commit this to disc.  I always assumed, naively
perhaps, that (2) did essentially that,  though that is of course not
the case if the file system decides to commit the result of (2e) before
(2c) and (2d).

So what is an application that rewrites a file (possibly not as the result of direct user action) supposed to do?  You suggest (3), but I can see a few drawbacks:
* If the file is overwritten twice in short succession, you'll get gratuitous disc writes.  This is the least of the problems and can be worked around inside the app by using a timer.
* fsync is expensive.  If your application can't afford to make a system call that can potentially block for on the order of a second, you're going to have to offload fsync to a seperate thread.  Not impossible, but not entirely trivial either.
* Calling fsync on a c++ ofstream looks like a major pita.

-- 
Ext4 data loss
https://bugs.launchpad.net/bugs/317781
You received this bug notification because you are a member of eCryptfs,
which is subscribed to ecryptfs-utils in ubuntu.

Status in “ecryptfs-utils” source package in Ubuntu: Invalid
Status in “linux” source package in Ubuntu: Confirmed
Status in ecryptfs-utils in Ubuntu Jaunty: Invalid
Status in linux in Ubuntu Jaunty: Confirmed

Bug description:
I recently installed Kubuntu Jaunty on a new drive, using Ext4 for all my data.

The first time i had this problem was a few days ago when after a power loss ktimetracker's config file was replaced by a 0 byte version . No idea if anything else was affected.. I just noticed ktimetracker right away.

Today, I was experimenting with some BIOS settings that made the system crash right after loading the desktop. After a clean reboot pretty much any file written to by any application (during the previous boot) was 0 bytes.
For example Plasma and some of the KDE core config files were reset. Also some of my MySQL databases were killed...

My EXT4 partitions all use the default settings with no performance tweaks. Barriers on, extents on, ordered data mode..

I used Ext3 for 2 years and I never had any problems after power losses or system crashes.

Jaunty has all the recent updates except for the kernel that i don't upgrade because of bug #315006

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
NonfreeKernelModules: nvidia
Package: linux-image-2.6.28-4-generic 2.6.28-4.6
ProcCmdLine: root=UUID=81942248-db70-46ef-97df-836006aad399 ro rootfstype=ext4 vga=791 all_generic_ide elevator=anticipatory
ProcEnviron:
 LANGUAGE=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.28-4.6-generic
SourcePackage: linux