On Sat, Jul 07, 2018 at 11:22:27PM -0700, Elliott Mitchell wrote: > It is easy to build wildly incorrect mental models of how a feature works > if you haven't looked at the code, but observed problems due to bugs... > > Particularly if the documentation doesn't talk about the implementation. > At which point confirming details identifies which are the crucial bits > to report.
Again, it's much easier if you tell me what you *see*, and not what your mental model might happen to be. A detailed reproduction is the most useful thing that can be in a bug report. In fact, it's what *I* do when I am first trying to diagnose and fix a bug, since a reliable repro means I can test to see whether or not I understand the problem, and whether or not a proposed fix can solve the problem. So if you give me a detailed, reliable repro, it saves me time, and this doesn't require a detailed mental model of how things work. In fact, if you had tried to create a reliable repro, with detailed instructions on how to reproduce it, you probably would have found the flaws in your proposed model.... > I'll be waiting for that news. I'm a bit unsure of where the bug should > be reassigned to... (hrmm, that is more kernel source packages than I > knew of) That was my point when I was trying to set expectations. You'll probably be better off applying the patch yourself, and probably, while you're at it, using a newer kernel than 4.9. Assigning bugs and expecting other people to do work for you may not work that well when you are trying to use exotic featues like MMP. You're free to do that, of course, but don't expect fast turnaround. > > (For example, if you want the fix right away, you may need to compile > > a new kernel yourself. And while an enterpise distro might be willing > > to backport MMP status feature in dumpe2fs to an ancient e2fsprogs, > > that's not going to happen for Debian Stable. You'll probably have to > > build e2fsprogs 1.44.3 for yourself and install it on your system.) > > Yawn. Been there. Done that. Not like I've built 1.2.13 and examples > of most kernel series since then (oh wait! I *have*!). Nor that I've > been paid to do system administration or software development (oh > wait...). > > I may end up fighting libtool, at which point a number of library > dependancies may start getting downgraded from "Depends" to "Recommends" > or "Suggests". Fortunately, build your own is pretty easy for both e2fsprogs and the kernel. Precisely because I don't use libtool. :-P Just check out the latest version from git, and run "sudo apt-get build-dep e2fsprogs" followed by "dpkg-buildpackage -us -uc -b". That's all that is necessary if you are using Debian. For the kernel, "make bindeb-pkg" will create for you Debian package files. They aren't built *precisely* the same way the Debian kernels are set up, but it's how kernel developers who use Debian build their own kernels. Sample kernel configuration files to build basic kernels sufficient for GCE and KVM can be found here: https://github.com/tytso/xfstests-bld/tree/master/kernel-configs See step (3) here if you need more details, but it's quite straight forward: https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md These configs are for non-modular kernels, which means you don't need to even install them if you are using KVM. You can just specify to the qemu/kvm binary an argument such as: --kernel /build/ext4-64/arch/x86/boot/bzImage and it will boot it without needing to install a kernel package (or messing about with grub). Or you can use "make bindeb-pkg" if you want a more tradiational installation. Cheers, - Ted P.S. You may find that if you do need to create reliable repros, using "kvm-xfstests shell" (see the kvm-quickstart instructions above) is a great way to experiment in a simple and fast sandbox. Also, if you are doing a lot of work with VM's, the technique for generating VM appliance images in a completely reproducible fashion may also be of interested. There are turn-key scripts and documentation for creating test appliance VM images for KVM and GCE images. (See slide 7 at https://thunk.org/gce-xfstests, entitled ``"Interesting technology bits inside gce-xfstests (or, “I’m not a file system developer, why should I care?”'')
