ecryptfs team mailing list archive

[Daniel Colascione <dan.colascione@xxxxxxxxx>]

@Arial

> No. If I overwrite a file the filesystem MUST guarantee that either
the old version will be there or the new one.

Err, no it's perfectly fine for a filesystem to give you a zero-byte
file if you truncate, then write over the truncated file. Why should the
filesystem try to guess the future and hold off on that truncate? As
long as the relative ordering of the truncate and write is preserved,
you're fine.

Why is it okay for the filesystem to give you a zero-byte file between a
truncate() and a write()? Because the filesystem gives you a facility
for asking for an atomic commit instead: write to a scratch file and
rename() that scratch file over the original. That's been the unix
technique since time immemorial, and it works fine.

1. When you need neither atomicity nor durability, truncate() and write().
2. When you need atomicity but not durability, write() to a temporary and rename()
3. When you need both atomicity and durability, write() to a temporary, fsync the file, rename, and fsync the directory.
4. When you need just durability, truncate(), write(), and fsync().

The problem isn't a zero-length file in cases 1 and 4. That's an
expected danger. You asked for those semantics but not using atomic
rename, so you can deal with them.

The real insidious problem is getting a zero-byte file under scenarios 2
and 3. rename() on top of an existing file should *always* make sure the
data blocks for the new file are committed before the record of the
rename itself is. It's absolutely critical that this work correctly
because there's no other good way of achieving atomicity.

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