Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752754AbbFVSs7 (ORCPT ); Mon, 22 Jun 2015 14:48:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48123 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751116AbbFVSsu (ORCPT ); Mon, 22 Jun 2015 14:48:50 -0400 From: Jeff Moyer To: Christoph Hellwig Cc: Dan Williams , Jens Axboe , "linux-nvdimm\@lists.01.org" , "linux-kernel\@vger.kernel.org" , Linux ACPI , linux-fsdevel , Ingo Molnar Subject: Re: [PATCH 14/15] libnvdimm: support read-only btt backing devices References: <20150622063028.GA30434@lst.de> <20150622072844.GA31263@lst.de> <20150622154138.GC7952@lst.de> <20150622163224.GA9168@lst.de> <20150622164804.GA9393@lst.de> X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? Date: Mon, 22 Jun 2015 14:48:48 -0400 In-Reply-To: <20150622164804.GA9393@lst.de> (Christoph Hellwig's message of "Mon, 22 Jun 2015 18:48:04 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1555 Lines: 36 Christoph Hellwig writes: > On Mon, Jun 22, 2015 at 12:42:44PM -0400, Jeff Moyer wrote: >> OK, add torn sector detection/recovery to that statement, then. More >> importantly, do you agree with the sentiment or not? > > I think we're getting on a very slipper slope if we think about > application here. Buffered I/O application must deal with torn > writes at any granulairty anyway, e.g. fsync + rename is the > only thing they can rely on right now (I actually have software O_ATOMIC > code to avoid this, but that's another story). OK, so you think applications using buffered I/O will Just Work(TM)? My guess is that things will start to break that hadn't broken in the past. Sure, the application isn't designed properly, and that should be fixed, but we shouldn't foist this on users as the default. > Direct I/O using application can make assumption if they know the sector > size, and we must have a way for them to be able to see our new > "subsector sector size". You need to let them determine that when NOT using the btt, yes. Right now, I don't think there's a way to determine what the underlying atomic write unit is. That's something the NFIT spec probably should have defined. > And thos application are few inbetween but also important so needing > special cases for them is fine. Although those are the most likely > ones to take advantage of byte addressing anyway. Agreed. -Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/