Re: [PATCH v3] fallocate: Add "--dig-holes" option

[Rodrigo Campos <rodrigo@sdfg.com.ar>]

On Mon, Feb 17, 2014 at 03:49:07PM +0100, Karel Zak wrote:
> On Mon, Feb 17, 2014 at 02:15:29PM +0000, Rodrigo Campos wrote:
> > On Mon, Feb 17, 2014 at 11:32:48AM +0100, Karel Zak wrote:
> > > On Fri, Feb 14, 2014 at 11:47:56AM +0100, Karel Zak wrote:
> > > > On Sun, Jan 26, 2014 at 03:06:50PM +0000, Rodrigo Campos wrote:
> > > > >  bash-completion/fallocate |   2 +-
> > > > >  sys-utils/fallocate.1     |  19 +++++++-
> > > > >  sys-utils/fallocate.c     | 114 ++++++++++++++++++++++++++++++++++++++++------
> > > > >  3 files changed, 120 insertions(+), 15 deletions(-)
> > > > 
> > > >  Applied with some changes and I believe that the code still need some
> > > >  improvements, see below
> > > 
> > > 
> > >  OK, I did some changes to the code:
> > > 
> > >  The minimal hole size is based on filesystem blocksize (st_blksize) and 
> > >  --length is no more used for this thing. I think it's better to use
> > 
> > This was not updated in the manpage, where it shows the run modes. It still
> > says on the top "fallocate -d [-l length] filename"
> 
>  Oh.. synopsis. Thanks, fixed now.

Np :)

> 
> > > 28K -rw-rw-r-- 1 kzak kzak 1.0G Feb 17 11:10 yyy
> > > ^^^
> > 
> > How did you create the file ? With fallocate ? Is it all zeros ? If it's all
> > zeros, 28K used seems like a bug maybe ?
> 
>  It's file with 6 holes with different sizes (1024, 10240, 102400 ....etc).

Ok, 28K may be okay then :)

> 
> > Any comparisson to see how much it took before (to see the improvement or the
> 
> old version:
> 
>         $ ls -lash yyy
>         1.1G -rw-rw-r-- 1 kzak kzak 1.0G Feb 17 15:39 yyy
> 
>         $ time ./fallocate --dig-holes
>         yyy
> 
>         real    0m0.525s
>         user    0m0.057s
>         sys     0m0.463s
> 
>         $ ls -lash yyy
>         164K -rw-rw-r-- 1 kzak kzak 1.0G Feb 17 15:39 yyy
> 
>  The 164K is because the small holes are ignored due to 32K buffer size.
> 
>  The speed improvement is probably because new code calls fallocate()
>  only when end of the hole is detected. The another possibility is
>  posix_fadvise(), but I have doubts that kernel readahead is so good.

Yeah, is probably avoiding the syscall IMHO too.

> > I can't test it in my new laptop because it fails to compile (autogen and
> > configure run fine). It throws:
> > 
> > 	rm -f ca.gmo && : -c --statistics --verbose -o ca.gmo ca.po
> > 	mv: cannot stat ‘t-ca.gmo’: No such file or directory
> > 	make[3]: *** [ca.gmo] Error 1
> > 
> > 
> > is this a known issue ?
> 
>  hmm... try git clean -xdf; ./autogen.sh ....

It's pretty much a fresh clone. I tried that and didn't help, also tried a
completely new clone, and fails the same way (same error). I'm using a Debian
testing/unstable in a 64bit machine now... (but doesn't seem 64bit related)

Will try to investigate later, when I have some spare time




Thanks,
Rodrigo