Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752710AbbFVTEY (ORCPT ); Mon, 22 Jun 2015 15:04:24 -0400 Received: from mail-wg0-f43.google.com ([74.125.82.43]:33498 "EHLO mail-wg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752243AbbFVTEH (ORCPT ); Mon, 22 Jun 2015 15:04:07 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150622063028.GA30434@lst.de> <20150622072844.GA31263@lst.de> <20150622154138.GC7952@lst.de> <20150622163224.GA9168@lst.de> <20150622164804.GA9393@lst.de> Date: Mon, 22 Jun 2015 12:04:05 -0700 Message-ID: Subject: Re: [PATCH 14/15] libnvdimm: support read-only btt backing devices From: Dan Williams To: Jeff Moyer Cc: Christoph Hellwig , Jens Axboe , "linux-nvdimm@lists.01.org" , "linux-kernel@vger.kernel.org" , Linux ACPI , linux-fsdevel , Ingo Molnar Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1533 Lines: 31 On Mon, Jun 22, 2015 at 11:48 AM, Jeff Moyer wrote: > 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. There are no atomic write units for NFIT to advertise beyond cpu register width. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/