Re: Btrfsck memory usage reduce idea

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

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.
>
>