From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Phillips <daniel@phunq.net>
Subject: Re: [FYI] tux3: Core changes
Date: Fri, 31 Jul 2015 10:27:13 -0700
Message-ID: <1981a91e-30a9-43ce-9a05-14aa777e46a5@phunq.net>
References: <alpine.DEB.2.02.1505252303120.3147@nftneq.ynat.uz>
 <67294911-1776-46b8-916d-0e5642a38725@phunq.net>
 <20150526070910.GA3307@quack.suse.cz>
 <a2233e75-a0bc-4732-9d6f-ad4d7cde0bae@phunq.net>
 <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>
 <CAGDaZ_oa7BY=70-7CGKoCFqnXbQjYVZ5pCurXh+FaGyKSv2Feg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Cc: David Lang <david@lang.hm>, Rik van Riel <riel@redhat.com>,
 Jan Kara <jack@suse.cz>, tux3@tux3.org,
 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
 linux-fsdevel@vger.kernel.org, OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Raymond Jennings <shentino@gmail.com>
Return-path: <tux3-bounces@phunq.net>
In-Reply-To: <CAGDaZ_oa7BY=70-7CGKoCFqnXbQjYVZ5pCurXh+FaGyKSv2Feg@mail.gmail.com>
List-Unsubscribe: <http://phunq.net/mailman/options/tux3>,
 <mailto:tux3-request@phunq.net?subject=unsubscribe>
List-Archive: <http://phunq.net/pipermail/tux3/>
List-Post: <mailto:tux3@phunq.net>
List-Help: <mailto:tux3-request@phunq.net?subject=help>
List-Subscribe: <http://phunq.net/mailman/listinfo/tux3>,
 <mailto:tux3-request@phunq.net?subject=subscribe>
Errors-To: tux3-bounces@phunq.net
Sender: "Tux3" <tux3-bounces@phunq.net>
List-Id: linux-fsdevel.vger.kernel.org

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?

Regards,

Daniel