linux-kernel - Re: [RFC PATCH 19/26] UBIFS: add Garbage Collector

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 1 Apr 2008 04:11:39 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Artem Bityutskiy <Artem.Bityutskiy@...ia.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Adrian Hunter <ext-adrian.hunter@...ia.com>
Subject: Re: [RFC PATCH 19/26] UBIFS: add Garbage Collector

On Thursday 27 March 2008, Artem Bityutskiy wrote:
> + * Note, if the file-system is close to be full, this function may return
> + * %-EAGAIN infinitely, so the caller has to limit amount of re-invocations of
> + * the function. E.g., this happens if the limits on the journal size are too
> + * tough and GC writes too much to the journal before an LEB is freed. This
> + * might also mean that the journal is too large, and the TNC becomes to big,
> + * so that the shrinker is constantly called, finds not clean znodes to free,
> + * and requests commit. Well, this may also happen if the journal is all right,
> + * but another kernel process consumes too much memory. Anyway, infinite
> + * %-EAGAIN may happen, but in some extreme/misconfiguration cases.

This comment sounds a little bit scary, but that may only be because I don't
understand the worst-case scenario.

Why can't you guarantee that there is always enough space to successfully
run GC, e.g. by reserving some space that can never be used by file data?

More importantly, if you get into the situation that the GC doesn't make
forward progress any more, can you guarantee that it is always possible
for the user to delete files in order to make space again? Or can you
get an -ENOSPC on unlink in that case?

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