tune2fs asks unwanted questions

[midenok]

tune2fs asks unwanted questions

[tytso]

The prompt is automatically disabled if stdin or stdout is not a tty (e.g., redirected to /dev/null, or to some other file). So
"tune2fs -U random /dev/XXXX < /dev/null" will not issue the prompt. Even if it is not suppressed, it just stalls for five seconds, before continuing. Note that this prompt shows up for file systems that (a) have the metadatta_csum feature enabled, and (b) does not have the metadata_csum_seed feature enabled. In that case, tune2fs will need to rewrite every single piece of metadata. This can take a huge amount of time for large file systems (far longer than five seconds), and if you crash in the middle of the tune2fs, the file system will be in a fairly sad state, with some percentage of the metadata blocks having invalid checksums. The only reason why metadata_csum_seed is not enabled by default for some distributions is because grub won't understand the metadata_csum_seed feature, and people were complaining when they were creating a file system on a new file system, and then finding out that it would be broken when used on older distributions with older kernels and/or older versions of grub.

So the current scheme was set up to warn users when they get surprised that running tune2fs in some cases could take hours and hours (at which point they would file bugs), as well as also trying to make it script friendly as much as possible (that's why the prompt times out after five seconds) and if the user won't see the prompt because the stdout is not the tty, or if the user can't answer the prompt because stdin is not the tty, the prompt will be shown. (And the reason why we some distributions don't enable metadata_csum_seed by default is because some users whined and filed bugs.)

So the moral if the story is that it's not possible to keep all of the users happy all of the time....

[midenok]

Yes, it's possible if one implements -y option or change -f. 5 seconds is too much (any delay is too much). I don't like it is asking me and I don't want to supply < /dev/null instead and wait. It produces false warnings because it doesn't take even 1 second for me. OTOH @tytso if you put false warnings everywhere your product will look like Google with its stupid and irritating gotchas. If operation takes too much time one can anytime press Ctrl+C and interrupt it. That was always the Unix way, not asking the stupid questions.

Well, I see this operation is not atomic, so the proper way is to implement atomicity. But the easiest way is to update -f. Would you accept patch for -f?

[tytso]

If you interrupt tune2fs -U while it is rewriting the metadata blocks, you will end up with a corrupted file system. So I don't recommend that. That is one of the reasons for the question followed by the five second delay, and it's not a "false warning". Potentially running tune2fs -U on a large file system could take hours --- especially if it is on a slower storage device like a HDD.

Ultimately, the right long-term solution is to enable metadata_csum_seed by default if you need to change the file system UUID on a regular basis. And then fix grub, et. al, to deal with this file system feature. (And since grub completely ignores the checksum, it's actually not hard to tell it not to barf when it sees this feature enabled. The patch has been submitted upstream to grub, and the one-line change is smaller than the patch to tune2fs which you are proposing.)

For now, if you are writing a script, I'm sorry if you think it's too painful to add "< /dev/null" to a line in the shell script. But ultimately, that's your problem, and not mine....

[midenok]

@tytso While I misguidedly told about script-friendliness my main pretension is about interactive use. Yes, I definitely don't want to type < /dev/null from command-line each time to avoid your warning. Is it my problem? Since the operation is not atomic it will end up in corrupted filesystem. This is evident, so you may not repeat it. Are you able to deal with questions asked or everything is others' problems?

When people use -U that means they cloned the filesystem, JFYI.

[tytso]

How often are you cloning file systems? Is it really that hard to wait five seconds or type "y"? As I keep saying, the long-term solution is to create the file system with the metadata_csum_seed option. Once that file system feature is enabled, the UUID can be updated atomically and quickly, and then there is no risk of corrupting the file system when it takes hours to update the UUID on a large file system on a slow device, and a user gets impatient and types ^C. And when metadata_csum_seed is enabled, then tune2fs will no longer give the warning which seems to offend you so deeply.

Upstream e2fsprogs enables metadata_csum_seed, but some distributions have disabled this default in /etc/mke2fs.conf, mainly because some users are building file systems on use to be used on older distributions where the bootloader doesn't support the feature. But give it another year or two, and another stable release of Debian (for example), and you won't have to deal with this warning any more.

Finally, you might want to consider how you present as someone who is extremely entitled, arrogant, and narcissistic, where you don't care about other users potentially corrupting their file systems, just because you can't be bothered to type "y" or just wait five seconds.

[midenok]

Can you understand what I'm talking about? How a special option will harm someone? Just be careful with the titles as every title voiced just characterizes the speaker.

It is not really that hard, but it is really that irritating since I cared to file the bug report (and really did not suspect it is so confusingly timeconsuming). I clone filesystems not often, but during that work I issue tune2fs -U dozen of times. I just noticed it is not unixway and since I don't see how my proposed solution can harm anybody I don't understand what is the problem to do that. It is simple topic and the solution is quick and simple. And your complex solution may have a chance to be never implemented. I also don't understand how this message can prevent everybody from the harm since it doesn't say about harm of interruption, so usually nobody will care and just hit 'y' as "long operation" is not the reason to not do what is required to be done.