Re: writepage return value check in vmscan.c

Andrew Morton (akpm@digeo.com)
Thu, 24 Oct 2002 12:25:20 -0700


Rik van Riel wrote:
>
> On Thu, 24 Oct 2002, Andrea Arcangeli wrote:
>
> > unfortunately I see no way around it and patching the kernel to loop
> > forever on dirty pages that may never be possible to write doesn't look
> > safe. You could check the free space on the fs and bug the user if it
> > has less than 2G free (still it's not 100% reliable, it's a racy check,
> > but you could also add a 100% reliable option that slowdown the startup
> > of the vm but that guarantees no corruption can happen).
>
> We need space allocation. Not just for this (probably rare) case,
> but also for the more generic optimisation of delayed allocation.
>

Well that's certainly the other option. Dig out the old
a_ops->reservepage stuff.

It _was_ Halloween 2003, wasn't it??

It would only work for filesystems which implement reservation
though, and iirc there were nasty problems doing delayed
allocation in, for example, ext3. I guess ext3 would have to
reserve journal space as well as disk space. ext2 delayed
allocation was pretty straightforward though, and most of
the infrastructure which it needed is there now. The replacement
of buffer-based writeback with page-based, mainly.
-
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/