> That said, as one of the change owners, I *want* to know about your > issues. Yes, I understand. It's just that I believe that the burden of proof is on my shoulders to prove that I have this and that issue before making bug reports. The problem I often face with btrfs is that it is highly inconsistent with its behaviour and that makes filling bug reports with concrete evidence of an issue difficult. i should just make videos of the issues or something. Most problems also only start after several months of serious usage and cannot easily be replicated in systems with other systems unless they're of exactly same model with exactly same kind of disks made. This isn't a problem if you constantly reformat your disks when hopping between distros but if you just want to continuously upgrade it will become an issue or at least does on my machines. For example btrfs has for a long-time had this issue where after several months and being maybe more than 75% of disk space being in use, that when run on SSDs, system can randomly stops reading from the file system, starts thinking and then eventually returns. With each freezing the condition gets worse and eventually the system is eternally stuck and power reset is required. The way this happens for example if you open Gnome Shell application launcher several times in a row, then likelyhood that Gnome completely freezes for duration of some seconds up to one minute increases. I don't see this behaviour when using any other file system so I've attributed it to btrfs but I have no way of knowing if it is an actual issue in btrfs other than it stopped when disk gets formatted to anything else. And also notice that I wrote "maybe 75% full" because there is no way to know the actual free disk space from just "df -h". There are chapters about this in btrfs FAQ pages that df lies about disk space when using btrfs since evaluating free disk space in btrfs system is a tricky and challenging task with no good solution in sight. This is why e.g. use of "btrfs fs usage /" is required together with other tools to have some idea of available disk space. > Well, huh, I've not heard of a recommendation about JFS in a long > time. For heavy I/O database workloads, I suggest XFS, though Btrfs > can be made to work quite well for database workloads with stuff like > nodatacow as I mentioned earlier. Yeah, that came out of an email which was written some years ago. I'm not planning on actively using anything else than ext4 or lvm+ext4 at the moment in my daily life. However as a result of the btrfs pushing I've started to look for alternatives if there was something what could improve my workflow. This includes testing out current state of JFS, BCacheFS, etc. I wanted to address some of the things you guys wrote but after several days I found myself writing more and more about just one particular thing. That thing being partitioning setup phase in Anaconda. Especially relating to the user's ability to easily choose an alternative configuration and customise the partitioning during the setup phase. I'll try to condense the most important points here. > It is actually quite easy to choose an alternative configuration if > you want. When you go through Anaconda installation and go to storage, > you can choose "Custom", and from there you have a drop-down list of > partitioning schemes: plain, LVM, LVM-thin, and Btrfs. You can select > any of those and have Anaconda do a default setup based on that. The > current default is "LVM", and we're changing the default to > "Btrfs". > But it's straightforward to make this change yourself at install time. > > In my experience, YaST is actually pretty hard to use to switch to > alternative configurations, so I'm surprised you say that it's > difficult in Anaconda but not in YaST. > No offense but you're really out of touch when it comes to this issue. Unlike Fedora, openSUSE has one the best partitioning setup phases I know about. In Fedora it is not easy to choose an alternative configuration or clearly comprehend what it is going to do to users disks. It is because of the UI design gone bad. It's also due low usability of Anaconda. Fedora's partitioning is over-engineered and too clever for its own good and it is like an hack intended to patch previous bad design. Ever since the times of around or even slightly before F21 things have gone bad with it. Thankfully blivet has been a real life-saver when it was introduced I think in F26 or F27 to Anaconda. Especially when you have two or more disks and just want to mount some partitions (e.g. /home) from one disk and reformat existing partitions (e.g. /root & /boot) on an another disk. Issues with Fedora's partitioning include (but are not limited to): 1. too many confusing separate steps, 2. no clear overview of what is actively being done to disks, 3. weird UI element placements with confusing labels, 4. similarly named selections which are totally different in actual functionality. When analyzing Fedora's partitioning with Jakob Nielsen's usability goals as the benchmark, partitioning in Fedora fails each of the five goals good (graphical) user interface should aim to be: I. For first-time users it isn't easy to accomplish basic tasks and learn through experimenting with it. II. It is not very efficient to use with users having mouse take round-trips around moon type distances on screen and clicking number of buttons and selections. III. It fails the memorability goal since due its complex nature after a while you have to re-learn it again. IV. It has high error state number and often leaves users unable to back off until they've give "correct answers" which is frustrating. V. It ultimately it isn't very satisfying to use. I also want to add that it makes assumptions that users know things they might in-fact not be aware of. Also help button doesn't aid them much. And the use of screen estate could be improved in a number of ways. For example in particular with the issue III.: Why in "installation target" step, once you choose "custom" or "advanced custom" storage configuration, the button to move to custom partitioning step is called "done" and not "next" or "continue" when it is clear that additional steps will follow? And why it's illogically placed at the top left corner instead of bottom right. This is inconsistent with Anaconda itself having just taught to user that to move to next screen from "language selection" step they need to click "continue" from bottom right corner. Most dialogs and wizards in Anaconda have their "accept", "next" and "cancel" actions in bottom right corner as well. But this is not true in "installation destination" screens. Furthermore in Microsoft Windows (which most users would be familiar with) the top left corner button tends to mean "return to previous step without saving changes" in install wizards. Also Anaconda fails to convey the difference of "custom" and "advanced custom" leaving users to try and see what they will get. In the openSUSE YaST partitioning is fairly straight forward process. It also fails some of the Nielsen's usability goals but in less serious ways. When you come to YaST's partitioning page, it will automatically detect storage devices and then suggest an automatic partitioning scheme for user. In Fedora you have to specifically choose it to do that for you. Also unlike Fedora, openSUSE will show you in text list of steps it will do if user chooses to accept the automatic partitioning. It isn't perfect but at least it's something. The openSUSE people could add more visual representation of how the HDD space is going to be sliced to improve this but this textual representation is great because it tells users step by step precisely what it would do if user accepts the suggested scheme. First automatic suggestion in openSUSE tends to go wrong (much like it goes in Fedora) but that's ok, YaST gives you two buttons to deal with this. First is "guided partitioning" which is extremely useful. It simply asks you couple questions in fairly consistent guided install wizard such as which disks to use if you have more than one, which file system to use for root, if you want LVM or not, if you want separate /home partition, if you want a separate swap partition, and so on. This alone makes it better for most new users than Fedora's back and forth way. With just three mouse clicks you've customised automatic partitioning and often with sane values. It's far easier to do plain ext4, lvm+xfs, btrfs or some other combination in YaST than in Anaconda. Because of this it doesn't really matter that openSUSE by default suggests to use btrfs since it's very easy to switch away from it. Furthermore the fact that you can constantly see a list of things it will do if you accept is great help. This is the way Anaconda should work as well. You can even very easily customise the suggested partitioning by clicking the "expert partitioning" which then offers you to start from scratch or suggested partition layout. And not only is YaST's "advanced custom" partitioning remarkably more comprehensive, it is also more simple to use and understand. you will see a proper device tree and you will see a proper list of partitions. Users can sort them and instantly see if operations are going to be performed and which operations in particular. Cherry on the top is that YaST can read recognise your existing Linux installation and read /etc/fstab and use that as a basis of suggested partitioning including the mount points. All this can be demonstrated using few screenshots as well if necessary. Fedora can learn a great lot from openSUSE's partitioning setup phase I think. Finally just think about the instruction you wrote about. You inadvertently admit within those instructions that it is more complex process in Fedora to switch to alternative layout than it is in openSUSE often in Fedora requiring more mouse clicks, more UI navigation, better in-depth understanding of what it is going to do to your disks and faith that it will actually do what you asked it to do. -- Antti (Hopeakoski) _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
