Quotes of the week [LWN.net]

So you can either try to drink from the firehose and inevitably be bitched about because you're holding something up or not giving something the attention it deserves, or you can try to make sure that you can let others help you. And you'd better select the "let other people help you", because otherwise you _will_ burn out. It's not a matter of "if", but of "when".

-- Linus Torvalds on git workflows (worth reading in its entirety)

I have spoken with engineers both individual and within companies who have developed and who plan to develop substantial kernel features. I'm forever explaining to people why they should work to get that code merged up. One reason for their not yet having done so which comes up again and again is apprehension at the reception they will receive. In public. This problem appears to be especially strong in Asian countries. You have just made the situation worse.

But it's not just a self-interest thing. It is inevitably and unavoidably the case that when one senior kernel developer acts like an arrogant hostile dickhead, we will all be increasingly regarded as arrogant hostile dickheads.

-- Andrew Morton

I suppose alternately I could send another patch to remove "remember that ext3/4 by default offers higher data integrity guarantees than most." from Documentation/filesystems/ext4.txt ;)

-- Eric Sandeen

(Log in to post comments)

It's all about the dreaded coding style issues (again!)

Posted May 22, 2008 2:47 UTC (Thu) by pr1268 (subscriber, #24648) [Link]

Andrew made a good point about how the kernel developers present themselves, even when the communication and interaction medium is e-mail. Although, I have to agree somewhat with Al's opinion that expending lots of time and energy merging patches whose sole function is to pretty-align function parameter arguments indicates misaligned priorities.

But, I don't agree with how Al vented his frustrations on LKML. Quite hurtful, IMO. That proposed new mailing-list address was especially uncalled for.

Those individuals/companies that Andrew mention, who are considering participating in Linux kernel development, need to have a thick skin if they're going to have to put up with ugliness like this on the LKML.

(Veering slightly off-topic in regards to Jianjun Kong's patches for which Al busted a gasket) I don't (currently) participate in kernel development, and it's a good thing--I've got such a bad case of (self-diagnosed) OCD--that I'd be doing nothing but re-writing entire .c/.h files just because I was dissatisfied with the coding style. I'm the pot calling the kettle black when I mention "misaligned priorities" above. ;-)

Ext3/Ext4 data integrity guarantees

Posted May 29, 2008 20:52 UTC (Thu) by anton (guest, #25547) [Link]

I turn off IDE disk write caching on all machines I maintain in order to really get the data integrity that journaling promises, and Andrew Morton drops data integrity patches because he worries about the speed impact of barriers and flushes (which are much less). If Linux used barriers and flushes to get data integrity, and I knew about that, I could turn on the write cache and see a speedup. However, I did not come across information about such issues despite being interested, and looking around now and then (and what I read did not inspire confidence), so I went ahead and disabled the write cache.

If I cared more about speed than data integrity, I would use XFS instead of ext3 in the first place. OTOH, if the Linux maintainers don't care for data integrity, maybe I should be looking for another kernel. Fortunately, looking through the thread, it seems that sanity seems to have come back to the Linux maintainers.

Concerning what can be lost with write caching enabled and without barriers, I have run a little test several years ago on two disk drives, and they both lost data that was several seconds old(er than data that ended up on the disk).