linux-kernel - Re: Tux3 Report: How fast can we fail?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <b47cf556-0887-43f7-b95c-6e508e40cf97@phunq.net>
Date:	Wed, 27 May 2015 11:28:50 -0700
From:	Daniel Phillips <daniel@...nq.net>
To:	Mosis Tembo <mosis.tembo@...il.com>
Cc:	Pavel Machek <pavel@....cz>, <linux-kernel@...r.kernel.org>,
	<linux-fsdevel@...r.kernel.org>, <tux3@...3.org>,
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Subject: Re: Tux3 Report: How fast can we fail?

On Tuesday, May 26, 2015 11:41:39 PM PDT, Mosis Tembo wrote:
> On Tue, May 26, 2015 at 6:03 PM, Pavel Machek <pavel@....cz> 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.

Regards,

Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/