Re: Btrfsck memory usage reduce idea

[Duncan <1i5t5.duncan@cox.net>]

Qu Wenruo posted on Mon, 21 Mar 2016 10:15:55 +0800 as excerpted:

> The point that I didn't want to keep the current behavior is, the old
> one is just OK or OOM, no one would know if it will OOM until it
> happens.
> 
> But the new one would be much flex than current behavior.
> As it fully uses the IO cache provided by kernel.
> 
> For machine with lot of memory, the whole IO will be cached except the
> first read.
> Making the difference between new and old implementation quite small.
> 
> For machine with less memory or the fs is just too large, at least
> btrfsck won't cause OOM.

That makes more sense to me, now.

I didn't initially post but I was worried about the tradeoff to much 
longer times, tho with lower memory requirements, on operations that can 
already take a long time.  But if as you say here the new, lower memory 
version makes use of cache so there shouldn't be a lot of difference on 
higher memory machines anyway, then yes, replacing the current 
implementation instead of providing an option so either implementation 
can be used, makes more sense, because otherwise one option will get more 
testing than the other, fixes to one might not carry over to the other, 
etc.

Tho as you suggest, possibly with a transition period during which both 
implementations are available, to work out any differences in results and/
or dramatically worse runtime cases.

Thanks. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman