Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751485AbbGaSgZ (ORCPT ); Fri, 31 Jul 2015 14:36:25 -0400 Received: from mail.lang.hm ([64.81.33.126]:47291 "EHLO bifrost.lang.hm" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751410AbbGaSgX (ORCPT ); Fri, 31 Jul 2015 14:36:23 -0400 X-Greylist: delayed 366 seconds by postgrey-1.27 at vger.kernel.org; Fri, 31 Jul 2015 14:36:23 EDT Date: Fri, 31 Jul 2015 11:29:51 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Daniel Phillips cc: Raymond Jennings , OGAWA Hirofumi , Rik van Riel , Jan Kara , tux3@tux3.org, Linux Kernel Mailing List , linux-fsdevel@vger.kernel.org Subject: Re: [FYI] tux3: Core changes In-Reply-To: <1981a91e-30a9-43ce-9a05-14aa777e46a5@phunq.net> Message-ID: References: <67294911-1776-46b8-916d-0e5642a38725@phunq.net> <20150526070910.GA3307@quack.suse.cz> <20150526090058.GA8024@quack.suse.cz> <5564D60E.6000306@phunq.net> <20150527084138.GD2590@quack.suse.cz> <87a8vtdqfz.fsf@mail.parknet.co.jp> <20150623161247.GP2427@quack.suse.cz> <87k2ueepd6.fsf@mail.parknet.co.jp> <20150709160528.GK2900@quack.suse.cz> <874mklaqbn.fsf@mail.parknet.co.jp> <1981a91e-30a9-43ce-9a05-14aa777e46a5@phunq.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2174 Lines: 45 On Fri, 31 Jul 2015, Daniel Phillips wrote: > Subject: Re: [FYI] tux3: Core changes > > On Friday, July 31, 2015 8:37:35 AM PDT, Raymond Jennings wrote: >> Returning ENOSPC when you have free space you can't yet prove is safer than >> not returning it and risking a data loss when you get hit by a write/commit >> storm. :) > > Remember when delayed allocation was scary and unproven, because proving > that ENOSPC will always be returned when needed is extremely difficult? > But the performance advantage was compelling, so we just worked at it > until it worked. There were times when it didn't work properly, but the > code was in the tree so it got fixed. > > It's like that now with page forking - a new technique with compelling > advantages, and some challenges. In the past, we (the Linux community) > would rise to the challenge and err on the side of pushing optimizations > in early. That was our mojo, and that is how Linux became the dominant > operating system it is today. Do we, the Linux community, still have that > mojo? We, the Linux Community have less tolerance for losing people's data and preventing them from operating than we used to when it was all tinkerer's personal data and secondary systems. So rather than pushing optimizations out to everyone and seeing what breaks, we now do more testing and checking for failures before pushing things out. This means that when something new is introduced, we default to the safe, slightly slower way initially (there will be enough other bugs to deal with in any case), and then as we gain experience from the tinkerers enabling the performance optimizations, we make those optimizations reliable and only then push them out to all users. If you define this as "loosing our mojo", then yes we have. But most people see the pace of development as still being high, just with more testing and polishing before it gets out to users. David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/