ecryptfs team mailing list archive

[Chris Cheney <ccheney@xxxxxxxxxx>]

Ted,

I am not sure if this was covered yet but if so I apologize in advance
for beating a dead horse.

The current opinion is that if you want to make meta data (eg the out of
order rename case) reliable you must use sync... Ok, that would require
a huge number of changes to many programs but it is at least
theoretically doable. However in doing so aren't you rendering laptop
mode essentially useless? As far as I know and from mjg59 confirmed was
the case you can't delay syncs. So now any time in the future any
application that wants its data to be reliable if only for meta data
cases it will cause a drive to spin up causing battery life to go down
the tubes. Yes SSDs are much more power efficient and are the wave of
the future, but from where I am it looks like they will continue to be
the wave of the future, what with even the Intel SSDs being only rated
for 20GB/day data transfer.

Also, you mentioned before that attempting to track meta data ordering
for files in memory would cause entaglement forcing a write of all data
to disk. Is that just due to the way the current kernel filesystem layer
works or a problem that is not fixable? If it were fixable then sync's
in code would only be needed for critical writes since meta data being
out of order would no longer cause the serious problems it does today in
cases with no sync calls. This would allow much more efficient power
management of hard drives since a laptop could potentially go for a very
long time without needing to spin up the hard drive (or bring the SSD
out of low power mode).

You also did mention that in the case of saving to a remote filesystem
that sync is actually needed to determine if it is even possible to save
to it. With the way the desktop in the past had worked, mounting remote
filesystems using the kernel and using posix apis, it was unknown what
the user would be saving to so apps might just sync to be safe. However
I think this case may not be as big of an issue anymore, on the desktop
at least, due to moving to api's such as gio which already know if they
are saving to a remote filesystem so can sync only in those cases, at
least aiui.

-- 
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: Fix Committed
Status in ecryptfs-utils in Ubuntu Jaunty: Invalid
Status in linux in Ubuntu Jaunty: Fix Committed

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