Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263915AbTH1K1S (ORCPT ); Thu, 28 Aug 2003 06:27:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263896AbTH1K1K (ORCPT ); Thu, 28 Aug 2003 06:27:10 -0400 Received: from ip213-185-36-189.laajakaista.mtv3.fi ([213.185.36.189]:52875 "EHLO oma.irssi.org") by vger.kernel.org with ESMTP id S262288AbTH1K0z (ORCPT ); Thu, 28 Aug 2003 06:26:55 -0400 Subject: RE: Lockless file reading From: Timo Sirainen To: David Schwartz Cc: Jamie Lokier , linux-kernel@vger.kernel.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1062066411.1451.319.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 28 Aug 2003 13:26:52 +0300 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 921 Lines: 23 On Thu, 2003-08-28 at 12:56, David Schwartz wrote: > > > You said that MD5 wasn't strong enough, and you would like a guarantee. > > > Yes. I don't really like it if my program heavily relies on something > > that can go wrong in some situations. > > Okay, this is too much. Your alternative, assuming the kernel won't > re-order writes, is clearly relying on something that can go wrong. Reorder on per-byte basis? Per-page/block would still be acceptable. Anyway, the alternative would be shared mmap()ed file. You can trust 32bit memory updates to be atomic, right? Or what about: write("12"), fsync(), write("12")? Is it still possible for read() to return "1x1x"? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/