← Back to team overview

ecryptfs team mailing list archive

[Bug 317781] Re: Ext4 data loss

 

@Theo:

Something is bothering me... I like laptop mode's ability to buffer
writes to memory while keeping the hard drive spun down. I have 4 GB of
RAM and wrote a script to cache a ton of system and user files to memory
so I can start programs, then edit and save files with the disk
remaining off most of the time.

Are you saying there's no safe way to save over a file without spinning
up the disk immediately? And that every file editor should call fsync
when saving? I don't want a spin-up to occur every time I save a file.
There's already a limit set for how long my data can be held in memory
before being written, so I'm not worried about losing ten minutes of
work in the rare instance of a particularly bad crash where I can't sync
before rebooting. But I am worried about the possibility of losing the
entire file.

So I want the update of the file to be safe, but I don't want to throw
away the benefits of laptop mode to obtain that safety. Ext3 has never
failed me in this regard and given me a zero-byte file, even though I've
allowed it to hold changes in memory for long intervals.

I see one of your patches forces the file data to be flushed out
alongside a rename when a file is replaced. Would the opposite be
feasible? That is, instead of flushing the file data earlier, hold off
on committing the rename until everything the file contained at the time
of the rename is flushed to disk. Hopefully doing it that way could
retain the performance of delayed allocation. Programs already use the
write-and-rename pattern to atomically create or replace files, and it'd
be nice if this atomicity was preserved even in the event of a crash.

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



Follow ups