On Mon, Mar 21, 2016 at 10:15:55AM +0800, Qu Wenruo wrote: > > IOW, there will be two options for the use to choose from, right? That's > > what I'd expect. Be able to check the filesystem on a machine with less > > memory at the cost of IO, but also do the faster check on a different > > machine. > > I was planning to use the new extent tree check to replace current one, > as a rework. > Am I always reworking things? :) The problem with big reworks is that there are few people willing to review them. So I'm not against doing such changes, especially in this case it would be welcome, but I'm afraid that it could end up stalled similar to the convert rewrite. > 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. That's a good point, for the single implementation. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
