Tomas M:
> Aufs manual says:
> These options are already implemented, but its design is not fixed
>
> Junjiro, would you please explain what that means? Is it safe to use
> trunc_xino? Is there a huge performance penalty? Thank you
It means some details of these features may be changed in the future,
including the interface (option names, optional parameters, etc...).
The current implementation is safe. No extra overhead. But as long as
the truncation surely consumes CPU, there is a necessary overhead.
Technically speaking, the truncation is a special file-copy. While the
plain file-copy handles the file "hole" as all zero-ed filedata, the
truncation skips such filedata by lseek(). So the result file doesn't
allocate the blocks for the hole.
For example, when 3 blocks are allocated to the file such like this.
(0xff x 4096 bytes) (0x00 x 4096 bytes) (0xff x 4096 bytes)
The plain file-copy will be
for (i = 0; i < 3; i++) {
read(src, buffer, 4096);
write(dst, buffer, 4096);
}
and the result file consumes 3 blocks too.
But aufs does
for (i = 0; i < 3; i++) {
read(src, buffer, 4096);
if (buffer is all zero)
lseek(dst, 4096);
else
write(dst, buffer, 4096);
}
so the result file consumes only two blocks.
J. R. Okajima
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
