From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751960AbbE0Vjz (ORCPT ); Wed, 27 May 2015 17:39:55 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:59017 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751064AbbE0Vjw (ORCPT ); Wed, 27 May 2015 17:39:52 -0400 Date: Wed, 27 May 2015 23:39:52 +0200 From: Pavel Machek To: Daniel Phillips Cc: Mosis Tembo , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, tux3@tux3.org, OGAWA Hirofumi Subject: Re: Tux3 Report: How fast can we fail? Message-ID: <20150527213952.GB15721@amd> References: <8f886f13-6550-4322-95be-93244ae61045@phunq.net> <55523C88.9080809@phunq.net> <20150526100326.GA8854@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 2015-05-27 11:28:50, Daniel Phillips wrote: > On Tuesday, May 26, 2015 11:41:39 PM PDT, Mosis Tembo wrote: > >On Tue, May 26, 2015 at 6:03 PM, Pavel Machek wrote: > > > >> > >>>We identified the following quality metrics for this algorithm: > >>> > >>> 1) Never fails to detect out of space in the front end. > >>> 2) Always fills a volume to 100% before reporting out of space. > >>> 3) Allows rm, rmdir and truncate even when a volume is full. > > > >This is definitely nonsense. You can not rm, rmdir and truncate > >when the volume is full. You will need a free space on disk to perform > >such operations. Do you know why? > > Because some extra space needs to be on the volume in order to do the > atomic commit. Specifically, there must be enough extra space to keep > both old and new copies of any changed metadata, plus enough space for > new data or metadata. You are almost right: we can't support rm, rmdir > or truncate _with atomic commit_ unless some space is available on the > volume. So we keep a small reserve to handle those operations, which > only those operations can access. We define the volume as "full" when > only the reserve remains. The reserve is not included in "available" > blocks reported to statfs, so the volume appears to be 100% full when > only the reserve remains. > > For Tux3, that reserve is variable - about 1% of free space, declining > to a minimum of 10 blocks as free space runs out. Eventually, we will > reduce the minimum a bit as we develop finer control over how free > space is used in very low space conditions, but 10 blocks is not bad > at all. With no journal and only 10 blocks of unusable space, we do > pretty well with tiny volumes. Yeah. Filesystem that could not do rm on full filesystem would be braindead. Now, what about 1) writing to already-allocated space in existing files? 2) writing to already-allocated space in existing files using mmap? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html