[prev in list] [next in list] [prev in thread] [next in thread]
List: util-linux-ng
Subject: Re: [PATCH v3] fallocate: Add "--dig-holes" option
From: Rodrigo Campos <rodrigo () sdfg ! com ! ar>
Date: 2014-02-17 15:42:21
Message-ID: 20140217154221.GA565 () sdfg ! com ! ar
[Download RAW message or body]
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
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic