Support for uncompressed sparse files.

[Pratik Shinde]

Hi Gao,

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).
For sparse files we have to do following
1) We don't want to allocate space for holes (Holes will be multiple of
EROFS_BLKSZ ?)
2) For read() operation on holes, return null data  = '\0'.

I have few thoughts about it:
1) Without changing the current design much, we want to keep track of holes
in file.
    e.g maintaining some table OR bitmap(per inode), to check if given
offset falls inside hole or real data.
2) Accordingly changing the readpage() aop.

Let me know you thoughts on this.

--Pratik.

On Sun, Nov 17, 2019 at 11:01 PM Gao Xiang <hsiangkao at aol.com> wrote:

> Hi Pratik,
>
> On Sun, Nov 17, 2019 at 03:40:43PM +0530, Pratik Shinde wrote:
> > Hello Gao,
> >
> > I have started working on above functionality for erofs.
> > First thing we need to do is detect sparse files & determine location of
> > holes in it.
> >
> > I was thinking of using lseek() with SEEK_HOLE & SEEK_DATA for detecting
> > holes.
> > Let me know what you think about the approach OR any other better
> approach
> > in your mind.
> >
> > PS : support for SEEK_HOLE & SEEK_DATA came in 3.4 kernel.
>
> That is a good start to detect sparse files by SEEK_HOLE & SEEK_DATA.
>
> And as the first step, we need to design the on-disk extent format
> for uncompressed sparse files. Is there some preliminary proposed
> ideas for this as well? :-) (I'm not sure whether Chao is busy in
> other stuffs now, we'd get in line with sparse on-disk format.)
>
> Thanks,
> Gao Xiang
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linux-erofs/attachments/20191125/51f9b6ff/attachment.htm>