[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <1208798974.14123.28.camel@localhost>
Date: Mon, 21 Apr 2008 18:29:34 +0100
From: "Ricardo M. Correia" <Ricardo.M.Correia@....COM>
To: Andi Kleen <andi@...stfloor.org>
Cc: Theodore Tso <tytso@....edu>, Eric Sandeen <sandeen@...hat.com>,
Alexey Zaytsev <alexey.zaytsev@...il.com>,
linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
Rik van Riel <riel@...riel.com>
Subject: Re: Mentor for a GSoC application wanted (Online ext2/3 filesystem
checker)
(sorry if this is a duplicate, my previous email was rejected)
Hi Andi,
On Seg, 2008-04-21 at 10:01 +0200, Andi Kleen wrote:
> > (I continue to be surprised at the un-safety of Linux fsync)
>
> Note barrier less does not necessarily always mean unsafe fsync,
> it just often means that.
Am I correct that the Linux fsync(), when used (from userspace)
directly on file descriptors associated with block devices doesn't
actually flush the disk write cache and wait for the data to reach the
disk before returning?
Is there a reason why this isn't being done other than performance?
I would imagine that the only reason a process is using fsync() is
because it is worried about data loss, and therefore is perfectly
willing to lose some performance if necessary..
Regards,
Ricardo
--
Ricardo Manuel Correia
Lustre Engineering
Sun Microsystems, Inc.
Portugal
Phone +351.214134023 / x58723
Mobile +351.912590825
Email Ricardo.M.Correia@....COM
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists