From mboxrd@z Thu Jan 1 00:00:00 1970 From: Howard Chu Subject: Re: [LSF/MM TOPIC] atomic block device Date: Sat, 15 Feb 2014 10:31:44 -0800 Message-ID: <52FFB290.3020305@symas.com> References: <52FFB1FE.9040300@symas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lsf-pc , linux-fsdevel , jmoyer , david , Chris Mason , Jens Axboe , Bryan E Veal , Annie Foong To: Andy Rudoff , Dan Williams Return-path: Received: from zill.ext.symas.net ([69.43.206.106]:48953 "EHLO zill.ext.symas.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753502AbaBOSbu (ORCPT ); Sat, 15 Feb 2014 13:31:50 -0500 In-Reply-To: <52FFB1FE.9040300@symas.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Howard Chu wrote: > Andy Rudoff wrote: >> On the other side of the coin, I remember Dave talking about this >> during our NVM discussion at LSF last year and I got the impression >> the size and number of writes he'd need supported before he could >> really stop using his journaling code was potentially large. Dave: >> perhaps you can re-state the number of writes and their total size >> that would have to be supported by block level atomics in order for >> them to be worth using by XFS? > > If you're dealing with a typical update-in-place database then there's no > upper bound on this, a DB transaction can be arbitrarily large and any partial > write will result in corrupted data structures. > > On the other hand, with a multi-version copy-on-write DB (like mine, > http://symas.com/mdb/ ) all you need is a guarantee that all data writes > complete before any metadata is updated. > > IMO, catering to the update-in-place approach is an exercise in futility since > it will require significant memory resources on every link in the storage > chain and whatever amount you have available will never be sufficient. > My proposal from last November could be implemented without requiring any more state than already present in current storage controllers. http://www.spinics.net/lists/linux-fsdevel/msg70047.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/