ecryptfs team mailing list archive

[Theodore Ts'o <tytso@xxxxxxx>]

@Volodymyr,

If you or someone else is going to run a statistical analysis, it's
better to wait until after the patches queued for 2.6.30 make it into an
Ubuntu kernel.   Also, you should when you did your test, did you check
to see about file lossagem, or just that the filesystem was self-
consistent?

Also, I can guarantee you that for certain classes of files, and for
certain workloads, you will lose data with ext3 if you put the system
under enough memory pressure.   Heck, with ext3 (since barriers are
disabled), if you are running with a very heavy workload that puts the
system under continuous memory pressure, the filesystem can be corrupted
badly enough on an unclean powerdown that it requires fsck to fix it.
Chris Mason proved that a few months ago.   The fact that you didn't
detect that just meant that you didn't rig your test that you happened
to catch that combination.

I can tell you what you will find with 2.6.30, which is that as long as
the newly written file is replacing an existing file using O_TRUNC or
file rename, the newly written file will be forced to disk before the
transaction commit is allowed to proceed.   However, for files that are
newly written and not yet fsync'ed, the data might not be saved until
45-120 seconds after it was written, and for files that are extended via
O_APPEND, or via an open(O_RDWR), lseek(), write(), newly allocated
blocks again may not be allocated until 45-120 seconds have gone by;
however these files are generally either log files, or database files,
and databases are usually competently written by people who understand
the value of using fdatasync() or fsync().

For both ext3 (and for files replacing other files in ext4) if the
transaction commit has not taken place, the new file contents will
obviously not be there, or be present with the "file.new" filename.   So
even for ext3, if your editor doesn't use auto-save files, and you are
doing a multi-hour long editing session without saving the file at
intermediate points, and then you save the file, and the editor doesn't
do an fsync(), and then before the five second transaction commit
happens, you fire up Google Earth or some other 3D application, *and*
you are using a crappy proprietary driver that causes a crash --- you
could lose hours of work.   Ultimately, there's only so much
incompetence and bad practices that a file system can protect you
against without completely sacrificing performance....

-- 
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