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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 27 May 2015 23:39:52 +0200
From:	Pavel Machek <pavel@....cz>
To:	Daniel Phillips <daniel@...nq.net>
Cc:	Mosis Tembo <mosis.tembo@...il.com>, 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 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 <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.

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
--
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/