Hi there !

I am about to install from scratch my desktop due to an upgrade in disks. My current disk failed and I will replace it to a new one. In fact, I will replace the boot disk too, not because it failed, but to upgrade in capacity.

The new disks are:
1) primary disks: SSD 480G SATA 3 for /boot and /, in dual boot with Windows.
2) secondary disk: 4T Seagate barracuda for /home and d:\Users in windows.

The question is: what kind/type of FS do you recommend ? Until now I was using ext4. I was wondering if btrfs (or even other recomendation) is ready to general use and if there is any significative advantage to use it over ext4 ?

I've tryied with btrfs a year ago or so, and at that time, GRUB couldn't manage to save the last choice on a btrfs for the /boot (GRUB_DEFAULT=saved;GRUB_SAVE_DEFAULT=true)

My MB doesn't have hardware RAID support, neither I have 3 or more identical disks to run a RAID5 setup.
And I am going with GPT/GUID, not MBR.
Also, my system is quite good: i7 with 8 cores, and 32G of RAM, for personal use. I don't have need to increase/decrease the size of partitions after installed, so, LVM is not necessary.

Of course, my goal is to have a FS which is fast and fault tolerant as much is possible, at least at FS level.

I am glad to hear your toughts about that. Should I stick with ext4 or move to btrfs or any other stable FS out there ?

I still only use ext4 for my systems disks - root, boot whatever.
I have used btrfs for many years for my "important" user data - photos in my case. In RAID5 against all the advice of the chicken littles that say that will cause the roof to rot and crash down. Bunkum.
The reason I like btrfs is snapshot - built in to the filesystem itself not grafted on like LVM, or a separate kludge as per snapper or rsnapshot. They all work to different extents, but I like btrfs. I would have gone with ZFS, but it wasn't available for Linux when I wanted it years ago. The latest (beta) release might make me change my mind, but I haven't tested it.

Note also that I am anal about (good) backups.

1 members found this post helpful.

On FreeBSD I use ZFS. On Linux I use ext4. Never once had an issue with ext4. I backup daily to my home NAS, which also gets backed up weekly to a USB drive. I can't compare performance between ZFS and ext4 because they are 2 different OS's and my FreeBSD build server is running SAS spinning disks while my PC is running SSDs. Performance on FreeBSD between UFS2 and ZFS for building (compiling) packages is greater using ZFS. I have no idea how ZFS performs on Linux.

To me, a file system should just work, with no fuss. I tend to be conservative about file systems because data is important. I don't care what FS the OS runs on because OS installation is easy. If the whole thing goes TU, no biggy. People have told me I should be running ZFS on my PC as well but frankly I don't understand the benefits. I only do it on my FreeBSD box because my build software is faster with it.

3 members found this post helpful.

I think I will use ext4 for the /boot (since grub play nice with), ext4 for / just to keep the system safe from my own stupidity and btrfs on a partition at same disk and setup volumes ( I don't know if it is the right name) to dynamically create /home and /opt and play with. May be I can add a second partition on a second disk to this setup and get the benefit of block checksum on theses volumes. Lets see...
Thanks guys for your time !

1 members found this post helpful.

I've never trusted BTRFS myself... still don't. But, it's been awhile since I DID use it last tho.

Same here - it's a good idea, and has saved my ass at least a few times now.

I think in answer to the OP's question; it really depends on their needs. Personally, I'd just go based on that.

I have been using ext4 in almost all my distros ─ except openSUSE.

openSUSE Leap is running on BtrFS "/" and XFS "/home" for 2 years now, and keeps solid.

Two Fedora installations gave me problems, but I don't know if ext4 was the cause. Next time, I will try its recommendation (XFS, I guess).

Then why do you need btrfs ? Its major advantage is the ability to resize subvolumes.

This is because LVM is not a filesystem. It is a type of dynamic partitioning. You format filesystems inside LVM logical volumes. LVM doesn't know what type of filesystem is contained inside. You can even format btrfs inside LVM LVs as someone on LQ did. You make a snapshot of the logical volume which can contain any filesystem you want. With this knowledge your comment about "grafted on" does not make sense.

Most of these "chicken littles" probably had problems with it and lost data. BTRFS Raid5/6 was not recommended for many years. Just because you have had no problems doesn't give you a right to put them down.

For desktop versions ext4 is the recommendation. xfs is the default only for servers.

4 members found this post helpful.

BTRFS is one of the file systems that has effective and mature detection and adjustment of defaults for SSD devices. Last I checked EXT4 was still somewhat lacking in this, but I have not checked recently. AIn any case, ajusting EXT4 to handle SSD better is fairly easy and well documented, and both are very solid options for a single drive (non-raid) use. EXT4 performs better on rotational drives, but for SSD I do not see much of a performance advantage.

My take is that the choice between them for this kind of use is a matter of personal preference and support in the distribution version you install. Your backup and recovery plan, resources, and practice matters FAR more than that particular choice of FS. Keep in mind, all devices DO fail in time and no FS defends your data from that fact.

Afterthought: EXT4 can be migrated to BTRFS at a later point, but I have not tested and do not recommend so migrating a boot volume.

1 members found this post helpful.

I tend to stick with the default FS the distro offers as I suspect (without any real proof) that it is more stable.

However Phronix tends to cover filesystem tests on various kernel levels and under different hardware. I'd go there for more clues.