https://bugzilla.kernel.org/show_bug.cgi?id=207635 --- Comment #5 from Joerg M. Sigle (joerg.sigle@xxxxxxxxxx) --- Eric, re. your other question: >I'm not sure there's anything else to do here, unless we were to make the >kernel ignore unexpected flags. >Ted, have you considered that? And it is intentional that e2fsck ignores >unknown flags? Please allow me some input on this: Someone might use a kernel with casefold or encryption support on Monday - and even use these features, causing a few of these flags to be set. The same person might run a kernel with casefold and/or encryption disabled on Tuesday. So, would it really be necessary to set their filesystem to ro - giving them a hard time, just because they like to use different kernels? I think not. There are many reasons to use different kernels: System-Rescue CD; kernel building experiments etc. So IMHO, a kernel that doesn't support a certain capability should not do *anything* with the bits used for that capability. It should make no assumptions about them, and at best not even look at them. Just leave them as they are. At most, it might write a warning to /var/log/messages. But it should not turn a working machine into a not working one for "reserved" bits being in a "surprising" state. There are other kernels out there, they might have some reason to set them as they are. (Saying this, I assume *and hope!* that it is generally no problem to use an fs that has these flags set with a kernel not supporting them - apart from the missing extra functionality.) This is just my naive opinion; I'm writing it however as someone who sees more and more complexity and unforeseen dependencies with bad side effects added to all areas of computing - often by people that were just a little bit too caring, or made too narrow assumptions on other peoples' usage scenarios. Thank you very much again, and kind regards, Joerg -- You are receiving this mail because: You are watching the assignee of the bug.
