LWN: Comments on "Thoughts on the ext4 panic"

Thoughts on the ext4 panic

neilbrown — Mon, 12 Nov 2012 05:10:52 +0000

The backups you need can take any of a range of values from none to offsite copies that let you reconstruct the state of anything at any moment.

Thoughts on the ext4 panic

kevinm — Mon, 12 Nov 2012 03:58:13 +0000

The need for backups is binary - you either need backups, or you don't need backups.

Thoughts on the ext4 panic

steffen780 — Sun, 11 Nov 2012 02:16:59 +0000

Sorry, but that claim is just wrong. Mirroring and replication do REDUCE the need for backups. They do, however, not ELIMINATE it. They protect against many forms of hardware failure, including what I would assume is the most common cause of hw-caused data loss: disk failures. Hence they reduce the need for backups. Of course they do not get rid of user-/app-level failures. They're not supposed to (and by definition cannot), and hence they do not eliminate the need for backups... but they do definitely reduce it.

Thoughts on the ext4 panic

nix — Thu, 08 Nov 2012 15:34:41 +0000

Quite. I did, after all, spot this problem on a hardware RAID-5 array. The RAIDness of the array didn't help: the corruption was faithfully written out. It had neither the evil nor corrupted bits set, after all.

Exceptions and rules

Wol — Thu, 08 Nov 2012 12:01:17 +0000

This comment actually gets to the root of the problem. The modern understanding of the word "prove" has changed.

Hence, the saying no longer means what it did, because the meaning of the words have changed underneath it.

Cheers,
Wol

Thoughts on the ext4 panic

dlang — Thu, 08 Nov 2012 07:49:51 +0000

to err is human, to really foul things up requires a computer

and to _really_ trash things requires automation :-)

automated replication (including mirroring) is a wonderful way to propagate corruption (as someone who has automated the trashing of several hundred systems with a single command, I can really attest to this one)

Thoughts on the ext4 panic

kevinm — Thu, 08 Nov 2012 06:00:59 +0000

Mirroring, whether to separate disks or separate machines, also does nothing to reduce the need for backups.

In the case of application- or user- level corruption, mirroring will simply replicate the error very efficiently.

Thoughts on the ext4 panic

anselm — Tue, 06 Nov 2012 18:25:20 +0000

Newspaper columns are as narrow as they are because that lets the publisher fit more stuff on a page and cut paper costs, not because narrow columns are especially easy to read.

Newspapers even go to the trouble of having special fonts designed for them (where do you think Times Roman got its name?) in order to be able to cram more type into a narrow column, thus making the effective column width greater.

Thoughts on the ext4 panic

marcH — Sun, 04 Nov 2012 23:37:43 +0000

> As for the ideal column width to read, go do some research on why newspapers use such narrow columns, the ideal width for reading is surprisingly narrow, and NOT 66 characters.

Source code and newspaper articles are quite different types of "literature". The are typically laid out in extremely different ways. It would be a very surprising coincidence if their "ideal widths" were the same.

Thoughts on the ext4 panic

daglwn — Thu, 01 Nov 2012 19:50:52 +0000

> I don't see a Linux IDE which allows this.

Emacs/CEDET.

Eight character tabs

etienne — Thu, 01 Nov 2012 12:06:48 +0000

But most of the time you want to understand the structure of the function you are about to modify, even if you have (probably commented) printf's showing that you entered the function with those parameters, that you are calling that other function with those parameters, what is the value of each of the fields of that structure...
Having 3/4 lines of code with no algorithm meaning does not help to see the structure of the code and is difficult to comment/uncomment at once; it is easier to tell your editor not to wrap lines and so not display the end of those (probably commented) lines.
Obviously you can write the functions print_mystruct_and_cpt(), print_mystruct_and_idx(), ... that you call only once in a commented out block.
Linux source do not have much "logging" lines, so it is not a real problem there.

Eight character tabs

ncm — Thu, 01 Nov 2012 09:41:15 +0000

Me, I've never understood why people insist that printf format strings should be indented at all. I push them to the left margin, and it brings no confusion, but much clarity.

Thoughts on the ext4 panic

ncm — Thu, 01 Nov 2012 09:32:04 +0000

"So many ways"?

1. Wrong

Any others?

Thoughts on the ext4 panic

Aliasundercover — Thu, 01 Nov 2012 03:52:27 +0000

> FYI, just checked and Eclipse (at least Juno/4.2) allows this. I can drag a source tab and place it next to my main source view

Hmm, I last poked at Eclipse a while back and got stuck in tile land till I gave up and moved on to try other IDEs which also left me in tiles. I find tiles most unsatisfying as I wind up spending my time fiddling with them and scrolling too small window fragments even on the biggest screen. I much prefer overlapping windows I can customize. I have been working in Kate which lets me arrange things as I like, permits multiple windows into the same source file and shares the screen well with windows from other programs.

Taking another look based on your message I got the Eclipse 3.7 Ubuntu offered me and found I can indeed get decent looking windows if I fiddle enough. It will take time to know if the fiddling stays excessive or I can tame it with more knowledge.

Of course it wants to mangle my code as I type. It really wants me to follow someone's idea of correct style and I know I will be some time getting it to stop helping me by making an awful mess of my code. Why exactly does it insist on extra * characters on each line? (No, don't answer that, I just want to turn it off.)

/*
* I can really do without these fool *s.
* Much preference fussing and still I get *s.
*/

Will have to see. Looking better than last time. Qt Creator and KDevelop never got me this far, not past tiles and tabs with them. So much IDE stuff filling the screen, so little space for the source code I actually care about.

Thanks

Eight character tabs

nix — Wed, 31 Oct 2012 18:52:06 +0000

I don't understand your debug printf() comment at all. You can always break a printf() line, even in the format string, with string literal concatenation.

Eight character tabs

marcH — Wed, 31 Oct 2012 18:09:33 +0000

"In theory, theory and practice are the same. In practice, they are not."

Eight character tabs

tialaramex — Wed, 31 Oct 2012 17:08:24 +0000

printf() - a function famous for never having been implicated in any complicated security bugs. Oh wait.

No, thanks all the same but I'd rather actually see the code I'm maintaining and not trust that the bits I can't see aren't important.

I like the ASCII control characters, but most of them don't belong in my source code and that includes U+0009 TAB. Use soft tabs, set the continuous integration software to barf on hard tabs in source code, along with mysterious trailing whitespace and similar sins.

Eight character tabs

nix — Wed, 31 Oct 2012 13:21:25 +0000

Variable-width fonts don't work at all for most programming languages for the reasons you state. I actually tried to use a variable-width font only for comments for a while, but it really messes up ASCII-art, and the places where you find ASCII-art in comments are generally the places where the code is complex enough to *need* it, and you don't want to have difficulty piled on by interpreting proportional-font damage too.

Thoughts on the ext4 panic

nix — Wed, 31 Oct 2012 13:20:00 +0000

Emacs has always been able to split the screen, since long long before X support existed. (It calls the panes 'windows' and the GUI windows 'frames' because Emacs does everything differently.)

Emacs 24 can split the screen, both manually and automatically, in so many ludicrous ways I have not begun to explore the possibilities. (The window-management code was rewritten by Martin Rudalics, and the new code is... very flexible. Almost too flexible to understand.)

Eight character tabs

nix — Wed, 31 Oct 2012 13:17:59 +0000

Yeah, automated reindentation before commit only works if you have something pre-commit that reindents again. I've worked on projects with such rules, and it does work (certainly better than what we had before, with people with all sorts of tab widths and odious 'optimizing' editors that translated spaces to tabs of whatever width the user had set throughout the entire file on every save). Better yet is to adapt to whatever the coding standard of the project is and just eat your whining most of the time. (Says the guy who whined about part of the kernel's coding standards just a few posts up. Hypocrisy is *good* for you!)

Eight character tabs

etienne — Wed, 31 Oct 2012 11:40:17 +0000

> spaces are nice and uncontroversial and always work. Tabs don't.

Well, have you ever used an editor with variable width font?
Why - maybe because text is easier to read...
Then, you can only use tabs to align stuff - unless that is the beginning of the line. If you comment a line using "//" at its beginning stuff stay aligned.
I do not want a hard limit on the number of chars, because not all chars are the same width...

Also, in some case (long debug printf() line), breaking the long line makes the structure of the function more complex than it really is; just tell you editor not to wrap and just ignore the end of the printf() line - it is just a printf()!

Eight character tabs

Jonno — Wed, 31 Oct 2012 11:37:32 +0000

Lining up arguments in tab-indented code works just fine, iff you use the same number of tabs for indentation, and then line up the arguments with spaces.

Thoughts on the ext4 panic

cesarb — Wed, 31 Oct 2012 09:25:42 +0000

> What is it with the IDEs not allowing multiple source windows? [...] I don't see a Linux IDE which allows this.

VIM has split/vsplit. Qt Creator also has split modes. And as others have already noted, Eclipse also has something of the sort. IIRC, Emacs can split the screen too.

Eight character tabs

man_ls — Wed, 31 Oct 2012 08:52:52 +0000

You can try telling git to ignore whitespace.

My point of view is a bit different: tabs are good, therefore avoid everything that doesn't work with tabs. Lining things up is evil, hard wrap-up limits are evil, and so on. Yes, it requires a lot of discipline, but then so does software development in general.

Thoughts on the ext4 panic

marcH — Wed, 31 Oct 2012 08:40:05 +0000

> but I don't know if I'd consider managing a full screen eclipse along with other windows "easy"

No it's not easy; you are not supposed to do that. Instead, you are supposed to install and use whatever plug-ins give you the functionality you need *within* Eclipse.

Eclipse is the new Emacs: a Developer Operating System :-)

http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.ecl...

Eight character tabs

bronson — Wed, 31 Oct 2012 01:05:02 +0000

... and then somehow unreindent before you commit your code? Otherwise, unless you enforce company-wide indent settings (good luck!), most of your changes will be whitespace churn.

I'm at the point where I'm ready to declare that, on a real world codebase with multiple teammembers, nothing at all works. Nobody likes the whitespace gestapo.

Exceptions and rules

nix — Wed, 31 Oct 2012 00:43:34 +0000

Agreed. I guess this just shows that the ext4 problem really *was* a tempest in a thimble (too small to be a teapot): thoroughly dull once the panic died away and its complete lack of terrifying implications sank in.

Eight character tabs

nix — Wed, 31 Oct 2012 00:42:07 +0000

Unfortunately changing indentation on the fly by changing tabs never, ever works. It only works if all developers are utterly rigorous about only ever indenting with tabs, always indenting with strictly one more tab, never using tabs to line anything up -- and, oh yes, never trying to make anything line up at all. If you like a coding style which lines up wrapped parameters one column after the open bracket of the call on the previous line (a very common style) you cannot do it, even with tabs, and expect indentation-changing-via-tab to work.

I have never worked on a codebase where changing indentation via tab width changes did anything but turn the codebase into goo. It is hopeless.

The way to reindent is via automatic reindentation programs (such as GNU indent). Teach that your indentation style, and you're home free. Nothing else works.

Eight character tabs

man_ls — Tue, 30 Oct 2012 21:49:19 +0000

The problem with spaces is exactly that you cannot change indentation on the fly just by changing the local configuration. Every developer can choose the tabstop that suits them better. It is even possible to have different configurations for different situations: one for the laptop screen, another when the laptop is hooked to a monitor, etcetera. Spaces don't allow that.

Also, it takes longer to press space four times (or eight) than tab once. You can usually configure your favorite editor to insert the spaces when tab is pressed, even to delete them (:set expandtab in vim), so this issue is not so important.

As to the failure case you mention above, it makes sense to indent always using tabs, consistently. I have now remembered my painful days of aligning arguments using spaces -- it is just not worth it. I prefer to use short argument lists and set line wrap at 120 so I don't ever see multi-line argument lists; if they arise then just indent into a new line.

Thoughts on the ext4 panic

khc — Tue, 30 Oct 2012 21:17:16 +0000

But only if all the windows you need to manage are eclipse windows, of course. I recently started to play with Dart using the Dart Editor which is basically eclipse, it works ok, but I don't know if I'd consider managing a full screen eclipse along with other windows "easy"

Thoughts on the ext4 panic

dlang — Tue, 30 Oct 2012 21:00:07 +0000

80 characters was based on 10 characters per inch on standard typrwriters combined with 8 1/2" wide paper and the fact that you needed margins of ~1/4" to avoid problems with trying to type up to the edge of the paper.

When teletypes were built, they used the same print mechanisms and so had the same limits.

When terminals were built, they mimicked the printed stuff (so that you could see everything that you could see on the paper, and it was a waste to have anything wider, since the people who were still using paper wouldn't be able to see it)

IBM punch cards were 80 columns to match the paper as well.

The problem is none of these are good reasons any longer.

As for the ideal column width to read, go do some research on why newspapers use such narrow columns, the ideal width for reading is surprisingly narrow, and NOT 66 characters.

a paperback book is about the outer edge of what a good width is (no matter what the font size)

Exceptions and rules

cmccabe — Tue, 30 Oct 2012 20:01:16 +0000

Usually comments on LWN are very informative. This thread however, is the exception that... never mind.

Thoughts on the ext4 panic

vonbrand — Tue, 30 Oct 2012 18:53:57 +0000

According to Poynton's "Ten Common Mistakes in the Typesetting of Technical Documents", a 66-character line of text is widely considered ideal for readability. I've seen other claims in the same vein (e.g. in the LaTeX memoir and KOMA packages documentation, aimed at serious book-writing). The 80 characters come from the IBM punched cards of yore, but their design in turn surely wasn't completely random either.

The decree from the $POWERS_THAT_BE is enshrined in the Linux coding style; trying to change that is futile (or at least, there are more fruitful outlets for your creative energies).

Eight character tabs

marcH — Tue, 30 Oct 2012 18:11:09 +0000

> But yes, over all, too many people will get tabs wrong that standardising on spaces - inferior as they are - is the only option.

Tab indentation was invented to illustrate "The perfect is the enemy of the good".

Let everyone have his own indentation taste from the same source? Great idea on paper. Falls apart on a regular basis. Because it's not compatible with lining up across lines, because it's not compatible with a max width, etc. And because people are only human and will not be disciplined enough.

Thoughts on the ext4 panic

marcH — Tue, 30 Oct 2012 17:26:59 +0000

It is indeed much easier to split and generally manage the screen with a full screen Eclipse than with most window managers.

Eight character tabs

nix — Tue, 30 Oct 2012 17:26:50 +0000

I don't see anything wrong with spaces. They make your uncompressed source code 10% or so larger, but these days that has no effect at all on anyone unless you're dealing with a source tree as large as, say, Chromium's. Everyone knows how big a space is, nobody can decide to make it take up more horizontal space... spaces are nice and uncontroversial and always work. Tabs don't.

Thoughts on the ext4 panic

salimma — Tue, 30 Oct 2012 15:10:01 +0000

... though when it comes to file systems, Apple's HFS+ is actually replete with seldom-used optional features - such as, mind-boggling as it might seem, case sensitivity.

But these are just exceptions that prove the rule... *ducks for cover*

Eight character tabs

paulj — Tue, 30 Oct 2012 14:41:29 +0000

Well, dealing with spaces has failure cases that just don't exist if you use tabs everywhere :). But yes, over all, too many people will get tabs wrong that standardising on spaces - inferior as they are - is the only option.

Eight character tabs

nix — Tue, 30 Oct 2012 14:32:52 +0000

Changing the local tab width is safe as long as you never ever use spaces to indent anywhere, even on the ends of tabs to line up arguments in multi-line argument lists. That's... rare, and if people proceed to change tab widths and then line up arguments using *that* width, the result is just a mess for everyone. (Just another reason why it is basically a mistake to use tabs for anything. Spaces everywhere! I note that even GNU software, long a weird 8-char-tab-for-indentation-but-four-char-indent holdout, is slowly switching to spaces, project by project, because dealing with tabs has failure cases that just don't exist if you use spaces everywhere.)

Thoughts on the ext4 panic

viro — Tue, 30 Oct 2012 14:14:37 +0000

oh, give me a break...

tagp = pointer; // fairly fat expression, actually
while (tagp - pointer <= size) { // again, and so's 'size'
tag = (journal_block_tag_t *) tagp;
flags = be32_to_cpu(tag->t_flags);
/* couple of lines */
err = jread(&obh, journal, io_block);
if (err) {
success = err;
printk(....);
} else {
/* about 50 lines */
}
skip_write:
tagp += sizeof(journal_block_tag_t);
if (!(flags & JFS_FLAG_SAME_UUID))
tagp += 16;

if (flags & JFS_FLAG_LAST_TAG)
break;
}

In a case. Wrapped in a while. Only at Dibbler's, and that's cutting me own throat...

Seriously, in this case 80-column heuristic has worked nicely - the code structure is badly obfuscated and 4-character tabs would only hide a visible indicator of trouble.