Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

Comp.os.research: Frequently answered questions [2/3: l/m 13 Aug 1996]
Section - [2.3.3] Inode ratios

( Part1 - Part2 - Part3 - Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Schools ]


Top Document: Comp.os.research: Frequently answered questions [2/3: l/m 13 Aug 1996]
Previous Document: [2.3.2] Block sizes
Next Document: [3] Papers, reports, and bibliographies
See reader questions & answers on this topic! - Help others by sharing your knowledge
From: Performance and workload studies

The BSD FFS statically allocates inodes.  By default one inode is
allocated for every 2K of disk space.  Since an inode consumes 128
bytes this means that by default 6.25% of disk space is consumed by
inodes.

It is important not to run out of inodes since any remaining disk
space is then effectively wasted.  Despite this allocating 1 inode for
every 2K is excessive.

For each file system studied I worked out the minimum sized disk it
could be placed on.  Most disks needed to be only marginally larger
than the size of their files, but a few disks, having much smaller
files than average, needed a much larger disk---a small disk had
insufficient inodes.

bytes per   overhead
  inode       (%)
   1024      12.5
   2048       6.3
   3072       4.5
   4096       4.2
   5120       4.4
   6144       4.9
   7168       5.5
   8192       6.3
   9216       7.2
  10240       8.3
  11264       9.5
  12288      10.9
  13312      12.7
  14336      14.6
  15360      16.7
  16384      19.1
  17408      21.7
  18432      24.4
  19456      27.4
  20480      30.5

Clearly, the current default of one inode for every 2K of data is too
small.  Earlier results suggested that allocating one inode for every
5-6k was in some sense optimal, and allocating one inode for every 8k
would only be 0.4% worse.  The new data suggests one inode for every
4k is optimal, and allocating one inode for every 8k would be 2.1%
worse.

The analysis technique I used is very sensitive to even a few file
systems with very small files.

The main source of file systems with lots of small files would appear
to be netnews servers.  The typical Usenet message would appear to be
1-2k in length.  Ignoring such file systems would drastically alter
the conclusions I reach.  If, as I believe might already be the case,
news servers are manually tuned to have a lower than normal bytes per
inode ratio, it would then be possible to justify setting the default
ratio much higher.

Clearly it is best if the file system dynamically allocate inodes; I
believe AIX does this for instance.  Systems that statically allocate
inodes should probably increase the bytes per inode ratio, but it is
not clear to exactly what value.  The engineer in me says `it is
important to play this one conservatively: stick to 6k', the artist
goes `as Chris Torek says: aesthetics, 8k'.



User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA




Top Document: Comp.os.research: Frequently answered questions [2/3: l/m 13 Aug 1996]
Previous Document: [2.3.2] Block sizes
Next Document: [3] Papers, reports, and bibliographies

Part1 - Part2 - Part3 - Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
os-faq@cse.ucsc.edu





Last Update March 27 2014 @ 02:12 PM