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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
