From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Mason Subject: Re: Write atomicity guarantees Date: Thu, 24 Apr 2014 14:44:21 -0400 Message-ID: <53595B85.4090703@fb.com> References: <20140424173909.GB5886@linux.intel.com> <53595209.50906@fb.com> <20140424182513.GD5886@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "Martin K. Petersen" , "Theodore Ts'o" , Dave Chinner , To: Matthew Wilcox , Purush Gupta Return-path: Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:35153 "EHLO mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758869AbaDXSno (ORCPT ); Thu, 24 Apr 2014 14:43:44 -0400 In-Reply-To: <20140424182513.GD5886@linux.intel.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 04/24/2014 02:25 PM, Matthew Wilcox wrote: > On Thu, Apr 24, 2014 at 11:10:09AM -0700, Purush Gupta wrote: >> That would require a new NVMe write command semantic with descriptors >> currently its not there. > > Yes ... I don't want to start defining such a command on linux-fsdevel. > What I'm hearing is that there's no benefit to a device that can guarantee > to write multiple contiguous sectors in a non-torn manner over a device > that can write a single sector in a non-torn manner. > > For any real benefit, filesystems need (and Linux needs to introduce > plumbing for) vectored atomic writes. > That's my feeling. The non-vectored use case is pretty limited, mostly to help get a contiguous log entry on disk as a full unit. But most of the time the filesystem log commits are pretty big. Workloads with a very small number of latency sensitive writers would see improvements. We could also the contiguous atomics for something like mysql by using a 16K sector size in the filesystem. At that point all of the db 16K units will be contig and the existing atomics proposals become interesting. But I was really hoping for the vectors ;) -chris