David Sterba wrote on 2016/03/18 19:18 +0100:
On Tue, Mar 08, 2016 at 04:46:41PM +0800, Qu Wenruo wrote:
1. Could you tell me what you'd like to do?
a) Provide completely the same function with current
implementation by other, more efficient way.
Same function, but less efficient.
It may takes longer time, more IO, but less memory.
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 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.
Another point is, the new implementation would be smaller and simpler.
For non performance critical case, the simpler code the better.
But that's not settled yet, maybe just like
multi-snapshot+quota+rebalance case, the old implementation may be times
faster on some special case.
So my teammate and I will keeps the old one until enough feedback.
Thanks,
Qu
And some error message will be output at different time.
E.g, error message for missing backref may be output at fs tree checking
time, instead of extent tree checking time.
This is acceptable.
--
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
