On 18/10/2017 17:14, Mark Clarke wrote: > Given the slow death of the ext file system it would be appropriate to > remove debugfs and dumpe2fs and with the growth in xfs I think it would > be more appropriate to give xfs greater attention. I have never used > debugfs nor dumep2fs for anything useful. Tune2fs used to be useful and > still is occasionally. > > Could someone let me know how to use debugfs and dume2fs in any useful > way? I really want to know as a non file system developer. I have > exhausted my google foo and the only example one ever sees about debugfs > is undeletling a file and this stopped working long ago as far as I > understand it.
I would agree with both of you. In 15+ years I have never used debugfs or dumpe2fs at all for any purpose. I would argue that that are barely even suitable at LPIC-2 level, never mind LPIC-1. tunefs still has reasonably frequent use. I use it a lot for fs label (I like to mount by LABEL=<thing> as opposed to by UUID) and for cranking that 5% reserved space way down as low as I can get it. On that topic, why are we still talking about 5% reserved for root in 2017? IIRC that comes from the mid-90s when 5% was a small number of inodes. Nowadays a 16TB fs is not uncommon, that 5% is 800G! An excessive amount of essentially unused space just so root can juggle some things around when the file system is "full" according to an unpriviledged user. I'm not sure I agree that xfs is worth a mention. If you need what it can do, it's awesome, but it always seemed to me a specialized fs outside of the normal and routine. Or maybe I just move in the wrong circles. btrfs is far more relevant than xfs imho. These days I use FreeBSD much more than Linux and there ZFS rules. I can't imagine doing anything resembling containerization (term used very loosely) without it, and btrfs filling that niche in Linux-land. I do agree that ZFS is not appropriate for a Linux exam as long as the licensing question remains in place. -- Alan McKinnon [email protected] _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
