xfs
[Top] [All Lists]

Re: question

To: Florin Andrei <florin@xxxxxxx>
Subject: Re: question
From: Steve Lord <lord@xxxxxxx>
Date: Wed, 30 May 2001 14:30:52 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: Message from Florin Andrei <florin@xxxxxxx> of "30 May 2001 12:12:17 PDT." <991249937.28873.4.camel@xxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
Link is also not a synchronous operation on xfs, if there is a crash before
the link is flushed from the log to disk then the link will disappear after
recovery. Running with the -o wsync mount option will make all transactions
synchronous - with a corresponding slowdown in all operations. This will make
the filesystem very safe, but not too fast. The patch mentioned - if it is
doing fsyncs in the correct place should also fix the issue for xfs.

Steve


> While reading the ReiserFS FAQ, i saw this:
> 
> #############################################
> Is Qmail *NOT* reliable with ReiserFS?
>     Qmail integration instructions are here:
> http://www.jedi.claranet.fr/qmail-ReiserFS-howto.html.
>     Qmail assumes that link() and unlink() are synchronous operations.
> Therefore, as soon as a message is received, Qmail writes it in mess and
> intd, creates a link in the todo directory for further processing, and
> tells the SMTP client that everything is all right.
>     With ReiserFS, link() is not synchronous. There is no guarantee that
> the message will be flagged for further processing by qmail-send if
> there is a power outage before the link is committed. The same problem
> may affect local deliveries.
> Here is a patch against Qmail 1.03 to correct that behavior.
> #############################################
> 
> Is this also true for XFS?
> 
> -- 
> Florin Andrei
> 
> "All operating systems suck.
> Linux just sucks less" - an MIT guy



<Prev in Thread] Current Thread [Next in Thread>
  • question, Florin Andrei
    • Re: question, Steve Lord <=