10.04 freeze trashes files

[treacl]

I'm having a major, recurring problem with OO 3.2.0 on Ubuntu 10.04.1, which I installed about a month ago.

Because of some driver incompatibilities with my laptop (a ThinkPad X201), the OS occasionally freezes. Three times in a month, this has been followed by a failed OpenOffice document recovery that has resulted in the last "saved" version of the file being wiped out. When I say wiped out, I mean a file that showed as 35k before the freeze now shows as 0 bytes, or 1536 bytes, or some other very small number.

My guess is that this is caused because the OS is holding the data in cache for far too long, and thus the data are lost when the OS freezes. I am wondering specifically whether this has to do with the file system and/or the way I have it configured.

My last Ubuntu system never had this problem: It was version 8.04, using ext3 in an encrypted lvm. The explicit fstab options for the main lvm were relatime,errors=remount-ro. (I understand that this also implies data=ordered.)

My current system is version 10.04, using an ext2 boot partition and a main ext4 file system in an encrypted lvm. The explicit fstab options for the main partition are data=ordered,barrier=1,noatime,errors=remount-ro.

Can anyone suggest what I should do to troubleshoot the cause and/or make this more reliable?

[treacl]

One additional point: What's lost in these freezes isn't simply the last few minutes of changes, or stuff I hadn't saved at all. When it happened today, I lost about fourteen hours' worth of changes on a file that had been saved repeatedly, opened and closed multiple times, etc. (Not saying that to document the severity of the problem, but in case the nature of the problem suggests anything meaningful.)

[Dustin2128]

by driver incompatibilities you mean?

[treacl]

Actually I was thinking more about the file system issues. Does my diagnosis (data loss due to delayed write) sound right? If so, is there a way to force ext4 to write data to disk more promptly? Or something else I can do so that I don't lose a day's worth of work on every open file every time the OS freezes? Because that gets a little tedious...

(I do of course want to fix the driver problems, too, but I'm putting that off because I understand that some of the fixes will be included in an upcoming kernel release, and installing kernel patches is very far outside my area of experience.)

Many thanks.

[treacl]

Sorry, just realized I misunderstood your question. There is a wireless card driver incompatibility/bug/whatever that causes the OS to freeze about 10% of the time when connecting. This is known.

There are also some problems with the i915 graphics card such that the OS has to be booted with "xforcevesa,i915.modeset=0"--i.e., with recovery-mode graphics. This is also known, and I believe that a patch is in the works. However, as far as I know this is not responsible for any freezes.

[Dustin2128]

Actually I was thinking more about the file system issues. Does my diagnosis (data loss due to delayed write) sound right? If so, is there a way to force ext4 to write data to disk more promptly? Or something else I can do so that I don't lose a day's worth of work on every open file every time the OS freezes? Because that gets a little tedious...

(I do of course want to fix the driver problems, too, but I'm putting that off because I understand that some of the fixes will be included in an upcoming kernel release, and installing kernel patches is very far outside my area of experience.)

Many thanks.
the diagnosis sounds quite possible, I'm googling and thinking about a solution...

[treacl]

Many thanks! Let me know what you come up with.

[treacl]

Okay, looks like I've stumbled up against this bug (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781), in which ext4's use of delayed allocation causes data loss (sometimes severe) if the OS crashes.

There is also this post (http://www.h-online.com/open/news/item/Ext4-data-loss-explanations-and-workarounds-740671.html) from March 2009, suggesting that using the "data=alloc_on_commit" mount option is the best way to avoid this, and predicting that the option will be implemented in kernel version 2.6.30, "at the earliest." I'm now using 2.6.32-25, and I can't find any documentation about this mount option. Does anyone know whether it has in fact been implemented? Or how to get the OS to list valid mount options for a partition?

Or what about the "nodelalloc" mount option?

If not, I may have to "downgrade" to ext3, which looks like an ugly and painful process no matter how you do it...

Thanks,
treacl