Je suis un Canadien grandpère anglaise. Même que j'aime la langue française, je m'exprime mieux en ma langue maternelle. Voici une mini document que j'ai préparé avec mes expériences concernant le système Fedora 27 installé sur un SSD avec interface btrfs.
Btrfs Btree file system, is supposed to reduce I/O to disk /SSDs. Sometimes what seems like a transparent implementation of Fedora onto a btrfs file system, ends up with causing side-effects that crash Gnome. I chose "btrfs" because it seemed to me that btrfs with it's
"copy on write(COW)" design would reduce the number of SSD rewrites, and thus prolong the time between
"fstrim" actions and as a consequence, prolong the life of the SSD.
Well, I can't dispute that theory, and thats why I used btrfs for my Fedora 26 and 27 Gnome installations. But there was a consequential side effect that caused me hours and hours of frustration, learning, experimenting, and blurting foul language when Gnome Shell would freeze, produce a system lockup, burp, etc.
I discovered, that for live files, opened once during your session, and "read/reread/written/rewritten" to, that btrfs with COW was changing the physical file location of a data portion after an update, even though the file was in use. Gnome shell, due to a some Gnome extensions would come along, not querying its settings, and retrieve trashed data from the original location. Thank you btrfs COW. I believe that the btrfs had relocated the physical location of the modified data. (Gnome shell should behave differently if the file system is btrfs, and not oblige btrfs to cater to Gnome).
Two solutions I considered are presented.
a) Change the folder that contains said type of file to non COW using btrfs-subvolume command, or
b) move the file to a non COW file system (eg, ext4 or xfs).
That discovery came several months after I began investigating the Gnome crashing issue, starting my research at the time of Fedora 26 alpha version. The file in question that caused the grief is ~/.config/dconf/user , and is about 16k in size. I relocated the file away from btrfs to an ext4 file system, to a static location on disk.
Thus, from my research, I gleaned more information about btrfs and I discovered this wonderful Phoronix site. Therein were some benchmarks prepared by "Michael Larabel" comparing btrfs, to f2fs, ext4 and xfs. The link following is an eye-opener. Linux 4.14 File-System Benchmarks: Btrfs, EXT4, F2FS, XFS
XFS is the fastest file system. I/O operations wth XFS are 2.5 times faster than with btrfs, and about 15% faster than ext4.
Furthermore, the negative side of xfs, from my perspective, is that the xfs file system can't be shrunk. If it is too small, it can be expanded, but not shrunk, It is also clustered, which uses a small amount of extra disk space, as a trade off. Every new file or folder is located on a new cluster, a multiple of the hard disk sector. So yes there is some wasted space. Even so, my entire Fedora Linux system fits onto a 50gig partition with 20gigs spare for growth.
Summary
if you are installing Fedora onto an SSD device, or a rotating hard disk, consider a "xfs only" file system for /home and /var. xfs provides the fastest I/O. Consider as well, if you have a hard disk and an SSD, of having /var, not on the SSD, but as a separate partition on the spinning disk. My justification, "Most operating system I/O takes place within /var. Most used is "/var/tmp". If you need temporary files, use /tmp, Fedora has it as "tmpdisk" in RAM. And with sufficient RAM (I have 8gigs of which 4 gigs are unused, which means that /swap is rarely, if ever used.
My configuration is such that I have / installed onto btrfs and /home onto xfs. /var is being relocated to a hard disk drive.
J'espere que cet affichage aidera dans les décisions concernant Fedora. Moi même, j'utilise RFRemix (Fedora spin) disponible via
http://mirror.yandex.ru/fedora/russianfedora/releases/RFRemix/27/Workstation/x86_64/iso/RFRemix-Workstation-netinst-x86_64-27.iso
Leslie de Montréal