@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 _______________________________________________ Mailing list: https://launchpad.net/~ecryptfs Post to : [email protected] Unsubscribe : https://launchpad.net/~ecryptfs More help : https://help.launchpad.net/ListHelp
