From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) by kanga.kvack.org (Postfix) with ESMTP id 3B2306B0009 for ; Fri, 26 Feb 2016 05:04:56 -0500 (EST) Received: by mail-io0-f177.google.com with SMTP id l127so117108412iof.3 for ; Fri, 26 Feb 2016 02:04:56 -0800 (PST) Received: from sabe.cs.wisc.edu (sabe.cs.wisc.edu. [128.105.6.20]) by mx.google.com with ESMTPS id w62si15952761iof.21.2016.02.26.02.04.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Feb 2016 02:04:55 -0800 (PST) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) (authenticated bits=0) by sabe.cs.wisc.edu (8.14.7/8.14.1) with ESMTP id u1QA4s6l020907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=FAIL) for ; Fri, 26 Feb 2016 04:04:54 -0600 Received: by mail-oi0-f51.google.com with SMTP id w80so2355367oiw.2 for ; Fri, 26 Feb 2016 02:04:54 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20160224225623.GL14668@dastard> <20160225201517.GA30721@dastard> <20160225222705.GD30721@dastard> From: Thanumalayan Sankaranarayana Pillai Date: Fri, 26 Feb 2016 04:04:29 -0600 Message-ID: Subject: Re: [RFC 0/2] New MAP_PMEM_AWARE mmap flag Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Dan Williams Cc: Dave Chinner , Jeff Moyer , Arnd Bergmann , linux-nvdimm , Oleg Nesterov , Christoph Hellwig , linux-mm , Mel Gorman , Johannes Weiner , "Kirill A. Shutemov" On Thu, Feb 25, 2016 at 10:02 PM, Dan Williams wrote: > [ adding Thanu ] > >> Very few applications actually care about atomic sector writes. >> Databases are probably the only class of application that really do >> care about both single sector and multi-sector atomic write >> behaviour, and many of them can be configured to assume single >> sector writes can be torn. >> >> Torn user data writes have always been possible, and so pmem does >> not introduce any new semantics that applications have to handle. >> I know about BTT and DAX only at a conceptual level and hence do not understand this mailing thread fully. But I can provide examples of important applications expecting atomicity at a 512B or a smaller granularity. Here is a list: (1) LMDB [1] that Dan mentioned, which expects "linear writes" (i.e., don't need atomicity, but need the first byte to be written before the second byte) (2) PostgreSQL expects atomicity [2] (3) SQLite depends on linear writes [3] (we were unable to find these dependencies during our testing, however). Also, PSOW in SQLite is not relevant to this discussion as I understand it; PSOW deals with corruption of data *around* the actual written bytes. (4) We found that ZooKeeper depends on atomicity during our testing, but we did not contact the ZooKeeper developers about this. Some details in our paper [4]. It is tempting to assume that applications do not use the concept of disk sectors and deal with only file-system blocks (which are not atomic in practice), and take measures to deal with the non-atomic file-system blocks. But, in reality, applications seem to assume that 512B (more or less) sectors are atomic or linear, and build their consistency mechanisms around that. [1] http://www.openldap.org/list~s/openldap-devel/201410/msg00004.html [2] http://www.postgresql.org/docs/9.5/static/wal-internals.html , "To deal with the case where pg_control is corrupt" ... [3] https://www.sqlite.org/atomiccommit.html , "SQLite does always assume that a sector write is linear" ... [4] http://research.cs.wisc.edu/wind/Publications/alice-osdi14.pdf Regards, Thanu -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org