Re: [Exim] Reliability of spool/delivery handling (Linux)?

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Miquel van Smoorenburg
Fecha:  
A: exim-users
Asunto: Re: [Exim] Reliability of spool/delivery handling (Linux)?
In article <20010822194616.B12527@???>,
Greg Ward <gward@???> wrote:
>On 21 August 2001, Philip Hazel said:
>> I'm afraid I don't have enough knowledge/understanding to follow how or
>> why that is relying on whatever it is that is worrying people. My
>> understanding of rename() is that it is atomic, that is, from the point
>> of view of other processes, either it has happened or it has not. There
>> is never a halfway state when neither the old file nor the new exists.
>>
>> If there really is a problem, please can somebody explain it to me in
>> more detail?


To be frank, I do not trust reiserfs in a production environment (yet)
myself. Until recently the fsck tools weren't even reliable - which
means that most things would be fine until you got a problem but
WHEN that happened it was impossible to recover.

If you want a journaling FS, get the linux-2.4-ac kernel series
and use ext3. That is something that I do trust.

>I don't understand it either, and I wish I did. The ReiserFS FAQ (at
>www.namesys.com, which is down as I write this -- argh) mentions
>something about Qmail on ReiserFS being problematic because of certain
>assumptions Qmail makes about the atomicity of certain filesystem
>operations.


That sounds suspicous. It also sounds reiser specific.

>At a round-the-water-cooler discussion this afternoon, I
>learned that Postfix makes similar assumptions, and ext2 (the main
>filesystem for Linux) similarly does not meet those assumptions. Now we
>learn that Exim is in the same boat as Qmail and Postfix, and ext3 (an
>update to ext2 which adds journaling) is in the same boat as ReiserFS
>and ext2. But I still don't understand what those various boats are
>really about at a nitty-gritty level.


Nothing to worry about, and certainly not the cause of the problem
in this thread. There was a huge flamewar about this subject on
linux-kernel recently, the thing is that Linux doesn't guarantee
that after a rename() operation all changes to the directory structure
are flushed to *physical* disk. All other processes will have a
consistent view, but if your machine crashes within a few second
after the rename() call, there is no guarantee that the effect of
the rename() call is still visible after the reboot & fsck.

So as I said nothing to worry about unless your machine crashes
20 times a day.

Mike.
--
"Answering above the the original message is called top posting. Sometimes
also called the Jeopardy style. Usenet is Q & A not A & Q." -- Bob Gootee