On Thursday 27 March 2008, Artem Bityutskiy wrote:
quoted text
> + * 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 <><
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/