<div dir="ltr"><div>Hi Gao,</div><div><br></div><div>In the current design, for uncompressed files, we only maintain the starting block address.because rest of the data blocks will follow it (continuous allocation).</div><div>For sparse files we have to do following</div><div>1) We don't want to allocate space for holes (Holes will be multiple of EROFS_BLKSZ ?)</div><div>2) For read() operation on holes, return null data  = '\0'.</div><div><br></div><div>I have few thoughts about it:</div><div>1) Without changing the current design much, we want to keep track of holes in file.</div><div>    e.g maintaining some table OR bitmap(per inode), to check if given offset falls inside hole or real data.</div><div>2) Accordingly changing the readpage() aop.</div><div><br></div><div>Let me know you thoughts on this.</div><div><br></div><div>--Pratik.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 17, 2019 at 11:01 PM Gao Xiang <<a href="mailto:hsiangkao@aol.com">hsiangkao@aol.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">Hi Pratik,<br>
<br>
On Sun, Nov 17, 2019 at 03:40:43PM +0530, Pratik Shinde wrote:<br>
> Hello Gao,<br>
> <br>
> I have started working on above functionality for erofs.<br>
> First thing we need to do is detect sparse files & determine location of<br>
> holes in it.<br>
> <br>
> I was thinking of using lseek() with SEEK_HOLE & SEEK_DATA for detecting<br>
> holes.<br>
> Let me know what you think about the approach OR any other better approach<br>
> in your mind.<br>
> <br>
> PS : support for SEEK_HOLE & SEEK_DATA came in 3.4 kernel.<br>
<br>
That is a good start to detect sparse files by SEEK_HOLE & SEEK_DATA.<br>
<br>
And as the first step, we need to design the on-disk extent format<br>
for uncompressed sparse files. Is there some preliminary proposed<br>
ideas for this as well? :-) (I'm not sure whether Chao is busy in<br>
other stuffs now, we'd get in line with sparse on-disk format.)<br>
<br>
Thanks,<br>
Gao Xiang<br>
<br>
</blockquote></div>