David Sterba wrote on 2016/03/22 15:49 +0100:
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.
So for convert rework, unless some other developer reviews the patchset,
it won't be merged, right?
To avoid the same problem, what about submitting small patchsets and
replace extent tree fsck codes part by part?
(Although not sure if it's possible)
Reviewers would be much more happy reviewing 5 patches for 5 times,
other than reviewing a big 25 patchset.
Thanks,
Qu
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
