I like BTRFS and it's features but sadly Debian doesn't have a preset for it in it's installer so the only way to use it is to manually partition and I absolutely suck at that.
Sorry if this is a dumb question, but have you tried using gParted? GUI, new-user friendly, easy to visualize your system, I’ve used it for over a decade on multiple devices…
Actually, I was using gparted yesterday! I was trying to format a USB drive to exFAT but the option was greyed out, so either gparted doesn't have support for formatting in exFAT or I needed an optional dependency.
Been running BTRFS since 2010. Ext2/3/4 before that.
Using it for CoW, de-duplication, compression. My home file server has had a long-lived array of mis-matched devices. Started at 4x2TB, through 6x4TB and now 2x18+4TB. I just move up a size whenever a disk fails.
I’m sure it’s great and all, but the hassle of having a filesystem that’s not in the kernel is a no-starter for me. Maybe one of those fancy NAS-distros that are based on some *BSD.
Linux works fine with ZFS. I wouldn’t use it as your boot device but for big storage it is very reliable and stable. It also can take advantage of ram with Arc and has optional special disks. (Metadata disk, slog and cache as an example)
Well, snapshots, too. I just consider them to be a special case of de-duplication.
I had an issue when I ran out of space during conversion between RAID profiles a few years back. I didn’t lose any data, but I couldn’t get the array to mount (and stay) read-write.
Ext4 is prone to corruption as it doesn’t have much error detection. Whatever you do don’t lose power.
I use Ext4 since 20 years in all of my systems. And I had my fair share of power loses. It’s not a problem as you describe, because Ext4 is journaling. Ext4 is robust and one should not worry to lose data randomly.
A file system that contains its own recovery capability in the event of a failure. In a journaling file system, the information about the changes is recorded in a separate log (the journal) before the indexes to the files are updated. If a power or other system failure corrupts the indexes as they are being rewritten, the operating system can use the log to repair them when the computer is restarted.
I believe you and understand that Ext4 is not 100% fail proof. But my point is, its extremely rare that Ext4 would corrupt the filesystem or files, even in an event of power loss (depending on many factors off course). I use Linux as my main OS since 2008 and since then Ext4. And I do not have these problems. My point is, Ext4 is a good and reliable option for day to day usage on a desktop PC, without worrying to lose data.
Also BTRFS isn’t stable for too long now and only a reliable option for a few years. Depending on the configuration, both filesystems can be a safe option to use. I agree that BTRFS has some benefits, including extended security over the data. I also plan on using it in the future. My only concern is, how you frame it and tell people how fragile Ext4 is, while it is not. Its a safe and good option for everyone, without the need for additional tools and special care like its needed with BTRFS.
Ext4 is a little fragile in my experience. It can get corrupted quickly when things go wrong. To be fair most hardware isn’t going to cause an issue and I have only had a issue a very small amount. However, when there is an issue fsck tends to fail as it has no way to check data integrity. The result is a completely broken system filled with corruption.
Btrfs and ZFS are superior as they check the data as it goes across. (Especially ZFS) That isn’t to say ext4 is bad as I just find it is hard to recover data from if things go very south. The benefit of ext4 is that is very simple. It doesn’t have support for subvolumes, datasets or anything like that but it does just work.
nope, it works really well, for more than a year now, this is my work PC using 8h/day, I’m using MX23 AHS version. Directly in the setup you can select encryption and btrfs volume etc. btrfs is pretty stable.
Edit: reasons added in because I can’t read the post title
OpenBSD laptop: ffs2, vfat for efi system partition
Why: Contrary to popular belief, OpenBSD does not support zfs. The only other filesystem options are msdos (fat family), and ext2fs (mostly for Linux compatibility as far as I can tell, filesystem is experimental and lacks a bunch of features according to the manpage). Makes ffs2 the only sane option.
Why: I prefer not having journaling on flash memory. This hasn’t bitten me in the ass too hard yet, and even when it does I can usually get around system files being lost with integrity tools. Maybe I’ll dabble with f2fs some day, but I’ll need to read about its features and shortcomings compared to ext2.
Alpine Linux VM: ext4
Why: Would have installed as ext2 as well, but I forgot
I prefer not using journaling filesystems on flash memory, I haven’t had any major data integrity issues yet because of it. I would have made the Alpine fs ext2 as well, but I guess I missed it during install. I think you can just disable journaling in ext4 anyways, so if I care enough I’ll just do that.
Every year I buy a couple ~$5 USB drives and plug them into my jbod machine in a software raid1. At this point there’s about a hundred in long array of daisy chained USB hubs.
Each drive is formatted with fat32 and added to an LVM. Don’t judge my ghetto NAS.
ext4 on all hard disks, but my installs are all several years old at this point, and I might choose differently if I were starting over from scratch. The boot partition on the ancient laptop might actually be ext2; I don’t remember and it’s certainly old enough that that might still have been preferred Gentoo procedure when I first set it up. Removable media might be ext3, ext4, or vfat, depending on compatibility needs and how long ago I formatted it. If I buy an SD card or USB stick that turns out to be preformatted in exFAT, I reformat it before use to ensure everything can read it.
They’re all solidly reliable filesystems (well, except for the vfat), but perhaps not the most featureful.
Yeah same here, everything is ext4 'cause it’s always worked and has never given me any troubles. But next time I have to reinstall I am tempted to give Btrfs a go.
I think btrfs was the default the last time I installed Bazzite, but I don’t really know anything about it so I switched it to ext4. I understand the snapshot ability is nice with rolling release distros, though.
It’d been ages since I’d used FAT32 for anything until I made a Debian live USB when I was setting up my pi-hole on an old Core2Duo recently. It would only boot on FAT32 for reasons I probably once knew. 😆
NTFS was an improvement over the FATs what with the journaling, security, file streams, etc. I use it wherever I still use Windows (work).
Most of my general purpose USB flash drives use exFAT. I like not having to worry about eject/unmount.
NTFS feels rock solid if you use only Windows and extremely janky if you dual-boot. Linux currently can’t really fix NTFS volumes and thus won’t mount them if they’re inconsistent.
As it happens, they’re inconsistent all the time. I’ve had an NTFS volume become dirty after booting into Windows and then shutting down. Not a problem for Windows but Linux wouldn’t touch the volume until I’d booted into Windows at least once.
I finally decided to use a storage upgrade to move most drives to Btrfs save for the Windows system volume and a shared data partition that’s now on ExFAT because it’s good enough for it.
By default, windows does “Fast Boot” which doesn’t make booting any faster, but does have the benefit of leaving the volume in a mounted state when you shut it down.
Oh, right. Fast Boot. I forgot about that bundle of joy.
But that’s wasn’t the only instance of an NTFS volume suddenly being broken. Another favorite was when I shrunk a volume on one disk from Linux (and then remembered that Windows correspond done it better) and rebooted to have it fixed and Windows proceeded to repair one on a different disk.
I mainly started using exFAT on flash drives (even on new ones) since it is interoperable between Windows, Linux, and Intel Mac. To be clear, I never don’t unmount the drive properly under normal conditions, but I remember reading around the time it was introduced that the Windows implementation guaranteed the buffers were flushed after every write (meaning no unwritten data remains when the activity indicator on the drive stops blinking) but now I can’t find any evidence that was ever the case. Wouldn’t be the first time I got bad info from the Internet. 🤷♂️
en.wikipedia.org
Active