My main concern is that such damage NEVER happened to disks partitioned to NTFS, whatsoever.
It may have never happened to you, but it has happened. The only filesystems that can claim things like this never happening are those that have never been exposed to such conditions. Even BTRFS and ZFS, which are both designed to be resilient against stuff like this, can have such issues.
To your actual questions though:
Is ext4 safe in general? I mean is it me or are there other people who experienced loss of disks/information on disks formatted to etx4?
It depends on what you mean by 'safe'. I've personally lost data on disks formatted with
ext4, but every time it's happened to me it's been due to bad hardware, and, more importantly, it would have happened eventually with pretty much any other filesystem. Despite this, I do still use it for numerous things on a regular basis because, barring user error or hardware issues (which includes unexpected power loss), it just works. So, I consider it 'safe' by most people's definitions, but you may or may not.
In Linux world, what could be a safer alternative to ext4 that can outlive unexpected electricity switch off or unexpected unmounting?
No, not unless you want to deal with other limitations or issues. In particular:
- XFS is a bit more resilient against unexpected power loss and doesn't need long checks on reboot like ext4 does, but has a number of practical limitations that make it questionable for small-scale use (can't shrink filesystems, performance isn't quite as good as ext4 on a new volume, can't do data journaling).
- NILFS2 is almost impossible to kill with a power failure, but you might lose 30 or so seconds of changes, it requires a userspace component when mounting, and it is missing a handful of features that are generally considered standard by most Linux filesystems.
- BTRFS will save you from failing hardware and reasonably reliably, plus it provides nice support for online replacement of failing disks, but again you may lose some of the most recent changes on an unexpected power loss, and you need to do a lot more to keep the volume healthy than for most other filesystems.
- ZFS has all the benefits that BTRFS does with none of it's issues (except the management ones), but it requires you build a third-party kernel module and you won't get get any upstream support for any issues you have if you're not running on enterprise grade hardware.
You can, however, do a number of things to make ext4 safer:
- Change the behavior when errors are encountered. By default, if an error is encountered in filesystem metadata, ext4 will just mark the volume as needing to be checked, and then act like nothing happened. It's the only filesystem on Linux that does this, everything else will remount the volume read-only, thus preventing any writes to the filesystem from making things worse. You can get this behavior on ext4 by adding
errors=remount-ro to the mount options, or running
tune2fs -e remount-ro on the block device containing the filesystem.
- Make sure you're not using writeback mode for the journal. Yo can ensure this by double checking the mount options for the volume and making sure that
journal=writeback is not in the list. Journal writeback mode can significantly improve the performance of certain workloads on ext4 filesystems, but it makes it much more likely that you lose data if you unexpectedly lose power.
- If you want to be really paranoid about data safety, you can enable journaled data mode. Normally, the journal on an ext4 filesystem only tracks changes to metadata (renames, file deletion or creation, timestamp updates, etc). In journaled data mode, all changes go through the journal. This slows things down significantly, but provides a functionally 100% guarantee that the file system will remain internally consistent. You can enable this by passing
journal=data in the mount options.
- You can add the
auto_da_alloc mount option. Essentially, this detects applications not calling
fsync() when they should, and properly handles things. It's not the default because it slows things down a bit, and most applications don't need it.
- On newer kernels, you can enable journal checksumming. This won't actually 'save' your data, but it will help ensure that you're not getting bogus data back when there was an error. This can be enabled by adding
journal_checksum to the mount options.
- If you've got a new enough kernel and version of e2fsprogs, you can enable metadata checksumming. Similar to the journal checksumming, this won't save your data, but it will help prevent you from seeing bogus data if there's an error. This has to be enabled at filesystem creation time, by passing
-O metadata_checksum,metadata_checksum_seed to
mkfs.ext4. If you do this, you (probably) don't need to also enable journal checksumming, as the journal is part of what gets covered by the metadata checksumming.