Hacker News Reader

Comment by userbinator | Hacker News Reader

Ironically, I've had far more problems with Linux systems using extfs losing data or requiring very lengthy fsck'ing after hard resets than Windows 9x or even DOS on FAT, despite experiencing more hard resets and routine hangs in my use of the latter.

I suspect the relatively more aggressive write caching of Linux and Unix-likes, combined with their more complex filesystem data structures, leads to a design in which unexpected resets easily cause lots of filesystem corruption. Contrast that with FAT's simplicity, minimal (effectively none) write caching, and the tradition of cutting power as soon as you returned to a DOS prompt. Maybe that's actually the true "worse is better".

View on HN

Yes, ext2, before journaling was added to extfs was painful, powerloss, or simply switching off a computer without runnng shutdown often resulted in data loss and if you're unlucky enough, fsck threw you in to "please try to fix this, I can't" prompt on the next boot.

"Ironically, I've had far more problems with Linux systems using extfs losing data or requiring very lengthy fsck'ing after hard resets than Windows 9x or even DOS on FAT, despite experiencing more hard resets and routine hangs in my use of the latter."

Your experience does not match the vast majority of users. The only OS I lost data on was on Windows when a drive crashed hard. When the same happened years later on Linux, I lost exactly nothing.

Yeah, I've been using Linux almost exclusively since 1994. I've had power outages and a few crashes but I can't remember ever losing data with ext2.

I don't remember losing a lot of data in DOS/Win3.1 but I rarely used it because it crashed so much.

I did have a lot of keyboard and X11 lockups in the 1990's but after a year I got a dumb terminal for $20 so someone could still check email, read Usenet, etc. while the main display was in use. If the main keyboard or X11 server locked up I could use the terminal to sync the filesystem and reboot the machine cleanly. I remember doing that quite a bit when playing full screen games or anything with SVGAlib

What does "drive crashed hard" mean? It can't mean the physical drive was toast, unless you're using some flavor of RAID in your daily driver.

I've had btrfs lose data several years ago from download-> quickly reboot without manual sync, as well as an ext4 system partition corrupted by unintended power loss (only once that I know of, many other times I had no issues).

extfs isn't a thing, and I say that because ext3 or 4 or even 2, matters here.

That spake, I wonder, are your bad experiences here with VMs, or with a raspberry pi?

Pis, especially the 2, had faulty hardware, and would report a successful write to an sd card before it was done. To "help" with speed.

This cause the sort of issues you are mentioning. And similarly, any situation where a write complete is a lie, can result in this behaviour too.

EG, a raid card with hard power off, no battery backed up cache, etc.

Because your experiences do not jive here, with ext4, and thousands upon thousands of servers and desktops I maintain.

> would report a successful write to an sd card before it was done. To "help" with speed.

Sadly USB sticks are handled the same way. The write notification and progress bar are long gone but you won't be able to eject that medium for several minutes.

Don't remember if it is the same on windows, since i use it rarely.

That's not the same, GP was talking about the hardware lying, not buggy software abstractions that affects measurements but don't lose data.

If you commit your database journal, you're told it's done and you start overwriting data, but the journal was never persisted... a loss of power will wreck your entire database.

Just run `sync`.

Didn't that not quite do what it says on the tin on some filesystems?

If the syscall meant to flush data to disk doesn't do that due to an implementation detail of a filesystem, I think there's nothing the user can reasonably do to ensure their data is safe.

way back when, unix admins were recommended to enter "sync" twice. this wasn't anything wrong with the program itself, but the time it took to enter the second sync gave the os to finish flushing its buffers to the hard disk.

Oh, for all my love of Linux, I really hate that bit of shitty UI. Then don't show a transfer bar at all.

>Pis, especially the 2, had faulty hardware, and would report a successful write to an sd card before it was done.

Interesting, do you know where I can read more about that? Or is this something you found out yourself?

The first version of the ext filesystem (ext1?) was in 1992. I had some friends who ran Linux then (one of them was a Linux developer) but ext2 was released in 1993. By the time I first installed Linux in 1994 ext2 was already the default and I remember documentation saying NOT to use the original ext

Journaling filesystems do not get lots of corruption "easily"

I staied away from XFS (on PC) because my experience was different. Power outage -> replay journal log (no fsck) -> repeat a couple of times -> filesystem corrupted heavily.

OTOH ext2 was rock solid.

> Ironically, I've had far more problems with Linux systems using extfs losing data or requiring very lengthy fsck'ing after hard resets than Windows 9x or even DOS on FAT,

This thread is wild. Are you saying you're still running Windows 98 and DOS machines (and for that matter Linux running a non-journaled ext3/4 device, something which no one has tried in decades)?!

Or is this literally a comment pulled from 1994? People really want to have an argument over the quality of a system in 2023 based on screaming we all did literally 30 years ago. Unbelievable.

Reply on news.ycombinator.com