Nikolay Pertsev:
> Apparently I can confirm both of the statements. The problem was discovered
> only because those 4 block are never reused. As I mentioned I have a
> completely diskless system. One day I found bunch of messages in my log
> file:
>
> Apr 14 03:40:01 plc-comm kernel: [3212661.041853] aufs
> au_xino_do_write:428:ln[15772]: I/O Error, write failed (-28)
> Apr 14 03:40:01 plc-comm kernel: [3212661.041861] aufs
> au_xino_write:464:ln[15772]: I/O Error, write failed (-5)
These values mean
- 28:ENOSPC:No space left on device
- 5:EIO:Input/output error
> So the filesystem is 100% used but I could not find what is consuming the
> space.
In order to see the blocks consumed by XINO files, see
/debug/aufs/si_<id>/xino* after reading aufs manual.
> > For tmpfs, it is enabled automatically.
>
> I am sorry if I am wrong, but I do not see this option being enabled
> automatically:
> Please, correct me if I am wrong somewhere.
>
> I just want to find correct solution for this situation. Should use
> "trunc_xino" mount option handle this? One of the questions I did not get
> answer on was (in first message):
> I would like to ask clarification about it - is it official solution which
> should be used ("trunc_xino") or there should be patch or something that
> fixes root of the problem?
I might be wrong about "automatically." Sorry about that.
I'd suggest you to try specifying "trunc_xino" after reading aufs manual.
This is official solution.
If you don't care patching against tmpfs, I can write and send one to
improve the inode number assignment in tmpfs.
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
