Linux file systems, inodes, fsck and lost 50GB files

[AZRedhawk44]

This is already resolved (very poorly) a week ago, but I'm curious what the best tactic is to deal with this in the future.

I had an Ubuntu build on a laptop.  I then put VirtualBox OSE on it and installed Win7, and several development tools.

Then I had a power outage.  Battery died.

Disk did not unmount cleanly.  It was an ext4 filesystem.

I messed with fsck for several hours.  I had a HUGE file that I could not recover, which was my VM VHD file.  I lost the work in the VM because I could not figure out a way to re-assign the inodes that were dumped into lost+found.

I've been bit by dirty dismounts in Linux several years ago on ext3, also.  Large lost file back then was a MySQL database which I had to restore from backup.

I never have this problem with Windows NTFS in its various incarnations.

How does one negotiate lost+found on a Linux file system?  How does one avoid this kind of problem?  It seems that HUGE amounts of files on ext3/ext4 end up getting sucked up to ram cache and marked dirty on disk, then not trusted on a hard reboot.  There's got to be a mount switch to avoid this behavior, or something.

What am I doing wrong?  The raw number of *nix based FTP/Apache/etc servers out there tell me that other people are able to hard-reboot them without losing the entire system or random large files.

[Brad Johnson]

How does one avoid this kind of problem?

Run Windows.

Brad

[Regolith]

Detcord.

[GigaBuist]

There's got to be a mount switch to avoid this behavior, or something.

Not really.  A brief reading on ext3 vs. ext4 tonight (I'm a bit out of the Linux game these days) confirms what I thought:  ext4 is going more for performance and is less likely to force a write than ext3.  Stick with ext3 if this is a concern.

But, basically, you've got to trust the apps to know when to call fsync().  If they don't do that the kernel won't be told it has to write to disk.  In the journaled filesystems that means just writing to the journal, not the actual filesystem, but they still have to call fsync() for it to certainly be there when the power comes back on.

NTFS isn't really any better, though the call on that side of the fence is _commit().  It was one of the last bugs I fixed on a project before I was laid off.  It had been known about for 2-3 years but nobody on the Windows side of our team had ever heard of fsync() let alone the Win32 counterpart.  Go figure.

[lee n. field]

ext4 is going more for performance and is less likely to force a write than ext3.  Stick with ext3 if this is a concern.

Interesting.  I'll remember that.

[GigaBuist]

Interesting.  I'll remember that.

Take it with a grain of salt.  I gathered that up after a few minutes research while doing actual work in another window and combined it with pieces of what I remember when the journaled systems hit Linux.

And, at that time, I went with reisferfs and didn't really pay attention to ext3 let alone ext4.  Unfortunately I think reiserfs is pretty much, uh, dead, for obvious reasons.