Hello Justin,
"Justin (jlec)":
> I also can reproduce the +4k problem with the procedure described here
> http://serverfault.com/q/445445/145512 and linux-3.13.3 + current aufs
> development HEAD.
>
> So, what is the problem now? Is this by design or is this still a bug?
The answer from me is essentially unchanged.
*Currently* I don't think it a bug nor by design.
You should try these steps.
- check the size and the number of the consumed blocks of XINO files via
debugfs and make sure they are big pressure for tmpfs.
--> In other words, are you sure that XINO files eat up your tmpfs,
or is it a general problem that your filesystem is too small for
your files?
If the XINO trunation feature in aufs doesn't work expectedly,
then it must be a bug.
- and then you can try "xino=/dir/file/on/another/place"
or
expand your tmpfs
or
"noxino" (which I don't recommend)
The background of this story is related to a specific behaviour of
tmpfs. That is how the inode numbers are allocated.
I wonder should I write a patch for tmpfs to change this behaviour...
J. R. Okajima
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
