ecryptfs team mailing list archive

[Theodore Ts'o <tytso@xxxxxxx>]

@3vi1,

At least for files which are constantly being replaced, the patches
which are queued to be merged into mainline at the next merge window
should cause ext4 to work no worse than ext3, and that seems to be most
people were complaining about on this bug.   Most editors, like vi and
emacs, are actually pretty good about calling fsync() when you save a
file.   I just checked OpenOffice, and it uses fsync() when it is done
saving a file as well.  So that tends to take care of most of the other
common cases.  (Things like object files in a build directly generally
aren't considered precious since you can always do a "make clean; make"
to generate them.

Personally, I test bleeding edge kernels all the time, and I've never
had a problem simply because I usually know before I'm about to do
something that might be dangerous, and so I just use the "sync" command
in a terminal beforehand.

The other thing that probably helps is that I also avoid hardware that
requires proprietary video drivers like the plague.   Why settle for
machines that crash all the time?   There are enough hardware options
out there that don't require proprietary video drivers, I don't
understand why folks would even consider buying cards that need binary-
only video drivers.   There's a reason why kernel developers refuse to
debug kernels that have been tainted by binary drivers; at least a few
years ago, Nvidia drivers had enough wild pointer errors that would
randomly corrupt kernel memory and cause hard-to-debug kernel oops and
panics in completely unrelated subsystems that they were pretty much
single-handedly responsible for the kernel "taint" flag infrastructure;
kernel developers were wasting too much time trying to debug buggy
binary-only video-drivers.

Finally, if you are really paranoid, you can mount your filesystem with
the "sync" option; this works for all filesystems, and will force writes
out to disk as soon as they are issued --- you can also toggle this on
and off by remounting the filesystem.  i.e., "mount -o remount,sync
/mntpt" and "mount -o remount,async /mntpt".     This will work for any
filesystem, as "sync" and "async" are generic mount option flags.

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