On Tue, 08 Jan 2013 02:13:28 +0900
sf...@users.sourceforge.net wrote:
> Jacek Konieczny:
> > Unfortunately, I don't have those logs around any more.
> > I have rebuilt the system to use 'noxino' option to mount aufs
> > instead. So far - so good...
>
> Of course it is your choice. And I hope you would understand the
> demerit of noxino.
Yes, I know some problems should be expected. Unfortunately I cannot tell
what exact problems I should expect.
> My recommendation is to estimate the size of XINO, prepare large
> enough to hold XINO, and specify it by "xino=". The aufs manual will
> help you to estimate.
This won't help, as the whole XINO file machinery is broken by design.
From the manual:
> The maximum file size of the table will be ’max inode number on the
> branch x size of an inode number’.
and, from the same manual:
> Actually TMPFS does not maintain the inode number at all. Linux kernel
> has a global 32bit number for general use of inode number, and TMPFS
> uses it while most of (real) filesystem maintains its inode number by
> itself.
So, the maximum inode number we can expect on tmpfs is 2^32, and the
size of the inode number is 4. So the expected size of the xino table
is 16GB. I have 200MB of RAM available for the file system and no
swap device. No way to pre-allocat 16GB there for the xino file alone.
Yes, xino file may be sparse, but then it is hard to estimate the size.
And, it seems, it won't ever get sparse if the truncation does not work.
IMHO a hash table should be used instead of the linear (even if sparse)
array for the xino data. Then the storage space could be used much more
efficiently.
Greets,
Jacek
------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
