<div dir="ltr"><div>Thanks Gao.</div><div><br></div><div>Now I understand the purpose.</div><div>So with i_format we will be able to recognize which path to take. i.e fast path (flat mode) or slow path(i.e to search through extent list).</div><div>I am working on it.</div><div><br></div><div>--Pratik.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 24, 2019 at 4:46 PM Gao Xiang <<a href="mailto:gaoxiang25@huawei.com">gaoxiang25@huawei.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Dec 24, 2019 at 04:15:47PM +0530, Pratik Shinde wrote:<br>
> Hi Gao,<br>
> <br>
> No no. What I am saying is - in the current code (excluding all my changes)<br>
> the block lookup will happens in constant time. with only hole list it<br>
<br>
Not only lookup but other interfaces such as fiemap, that is why called<br>
flat mode and fast path.<br>
<br>
> won't be O(1) time but rather we have to traverse the holes list. (say in<br>
> binary search way).<br>
> what I don't understand is - what is the purpose of tracking data extents.<br>
> hope you get it.<br>
<br>
Mode plain and inline are called flat modes, which is the most common<br>
case of regular and dir files. You can see that's the fastest path for<br>
most file accesses (minimum metadata).<br>
<br>
The reason why don't extend the flat modes but introduce another new<br>
sparse mode for 3 main reasons:<br>
 1) introduce a complete enhanced new extent table (or later B+-tree);<br>
 2) we don't even know how many holes in the file if we only read<br>
    inode base metadata, some extra header (no matter extent or hole<br>
    header) need to be readed in advance;<br>
 3) Old kernel backward compatibility need to be considered, not all<br>
    files are sparsed, and we need to get them work properly, and rest<br>
    files are sparsed, we need to block such files from accessed by<br>
    old kernels;<br>
<br>
Note that i_format is for such use, so we can introduce sparse mode<br>
with some enhanced on-disk representation (but with more metadata<br>
read amplification than flat modes).<br>
<br>
So if files without holes it should be considered as flat modes (fast<br>
path), and then considering the slow path --- upcoming sparse mode.<br>
<br>
The purpose of tracking data extents is we could then use it<br>
for deduping, repeated data or data redirect. Hole can only be 0<br>
though.<br>
<br>
Thanks,<br>
Gao Xiang<br>
<br>
> <br>
> --Pratik.<br>
> <br>
</blockquote></div>