Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753557AbbHRQjj (ORCPT ); Tue, 18 Aug 2015 12:39:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35137 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752754AbbHRQji (ORCPT ); Tue, 18 Aug 2015 12:39:38 -0400 Message-ID: <55D35FC6.9000005@redhat.com> Date: Tue, 18 Aug 2015 12:39:34 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Daniel Phillips , Raymond Jennings CC: OGAWA Hirofumi , David Lang , Jan Kara , tux3@tux3.org, Linux Kernel Mailing List , linux-fsdevel@vger.kernel.org Subject: Re: [FYI] tux3: Core changes 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> In-Reply-To: <1981a91e-30a9-43ce-9a05-14aa777e46a5@phunq.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1748 Lines: 42 On 07/31/2015 01:27 PM, Daniel Phillips wrote: > 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? Do you have the mojo to come up with a proposal on how to make things work, in a way that ensures data consistency for Linux users? Yes, we know page forking is not compatible with the way Linux currently uses refcounts. The question is, does anyone have an idea on how we could fix that? Not necessarily an implementation yet, just an idea might be enough to move forward at this stage. However, if nobody wants to work on even an idea, page forking may simply not be a safe thing to do. -- 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/