Alessandro Selli wrote: > > Which is a use that goes beyond what an LPIC-101 Minimally Qualified > Candidate is supposed to know.
Not making an argument either way, however ... A filesystem mounted over another filesystem is an extremely common (and poor) situation in any POSIX environmemt. One thing that continues to bother me in these discussions are the fact that the debates are over commands and inclusion preferences, instead if concepts and the tools that could be used to identify and/or solve them. Again ... not weighing in on the tool, but a filesystem mounted over a filesystem is an extremely common, poor, elusive and troubling scenario for 1st line Linux sysadmins. I've seen it handled very poorly by 1st level sysadmins too. Matt: Is there are "reference history" on why debugfs was included? That might go a long way to explaining it's inclusion, and the justification for Level 1 as well. I recently read Red Hat dropped support for BTRFS: > > https://servers-linux.ro/red-hat-to-drop-support-for-btrfs-linux-magazine/ > Red Hat to Drop Support for Btrfs ยป Linux Magazine > 09/08/2017 Clarification: Red Hat _never_ supported btrfs. Unlike most Linux distributors, Red Hat is extremely anal on the "support" term in it's "entitled" products. That's because whatever Red Hat "supports," it supports for 10+ years in many cases. Insert a lot of messy scenarios for various distributors that left a lot of customers in poor situations -- sans SuSE who really expends a lot to make good on its life cycle promises as well. File systems are one of those things where various distributors ship and support all sorts of options, and Red Hat does not. Btrfs had been in perpetual "tech preview" and Red Hat finally "yanked the plug" on most of it's engineering efforts --finally advising customers it hadn't reached the level maturity amd stability desired, and it would not for the foreseeable future. It still ships in Fedora, but the "tech preview" status is over in Red Hat Enterprise Linux (RHEL), having never gone to release status. This is rare, but has happened before. When it goes to "release," Red Hat is "married to it." In btrfs' case, it never made it to the wedding. Are there major distributions that do not use ext4 as the default > filesystem at installation time on servers, desktops and laptops? Yes, several have installers that still select Ext by default. And x86-64 (aka AMD64, also IA-32e) is often required for XFS too, so x86 (aka IA-32) doesn't include it. This has to do more with the userspace tools. Ext is not going anywhere anytime soon. That, plus, Ext (especially Ext4) and XFS are still extremely similar to each other in concepts. Other than xfs_repair (and xfs_rsr), most of the tools work the same. I agree here too I meant to bring this up earlier, but it's more important to understand what each tool does, is used for and addresses than debating the tool itself. I.e., tools that let sysadmins view super block and inode information is the focus. Sysadmins who dont understand the concepts and what is contained in the super block and inodes are going to have a much rougher time -- even at Level 1 -- than ones who do. The classic ... "Why is 'df' [always] so fast and why is 'du' usually much slower (at least the first time)?" That, plus, "What is this 'superblock' thing that the error message pointed out"? As I said, I've very worried people are debating commands and preferences, instead of the concepts addressed with the tools. Maybe Matt can provide some history and/or other references to explain why various tools were included? - bjs -- -- Bryan J Smith - http://www.linkedin.com/in/bjsmith E-mail: b.j.smith at ieee.org or me at bjsmith.me
_______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
