Hi everyone!
I am very sorry it has taken such a time for me to do this summary, but
I have been working a lot, plus I have gotten the flu *sigh*. Anyway, my
problem was that my advfs said it was full, even though I had lots of
space left.
I would like to thank these people for answering my question:
Michael Matthews <matthewm_at_sgate.com>
Huw Davies <H.Davies_at_latrobe.edu.au>
Simon Amor <spa_at_dmu.ac.uk>
Alan Rollow <alan_at_nabeth.cxo.dec.com>
Steve Hancock <hancock_at_alf.dec.com>
Steven E. Newton <snewton_at_oac.hsc.uth.tmc.edu>
Todd V. Minnella <minnella_at_husc.harvard.edu>
Mark E. Glidden <glidden_at_harvard.edu>
Stephen L. LaBelle <labelles_at_mscd.edu>
Warren T. <warrent_at_infi.net>
Martyn Brown <brown_at_whio.lincoln.ac.nz>
John Seel <johns_at_totaltec.com>
The reason this happens is that the filesystem runs out of metadata
space (think of it as the i-nodes on UFS). To avoid this, redo the
filesystem with the following option:
mkfdmn -x <your new value> <device> <domain name>
The default value for -x is 128, which, according to Digital, is the
equivalent of about 200.000 files.
I will also include some of the answers I got, that explains this a
little bit deeper than I do.
Included e-mail from Simon Amor:
The inodes are apparently stored in some kind of index called an
"extent" I think and it's the extent which is full. Try cd
$NEWSSPOOL/.tags ; showfile -x M-6 | more to view the "extent"
structure.
Id Vol PgSz Pages XtntType Segs SegSz Log Perf File
fffffffa.0000 1 16 60418 simple ** ** ftx 96% M-6
extentMap: 1
pageOff pageCnt vol volBlock blockCnt
0 2 1 32 32
2 1024 1 9744 16384
1026 1024 1 617744 16384
2050 1024 1 891696 16384
^^^^^^
this value will probably be 128 on your news spool.
--------
Included e-mail from Alan Rollow:
Known bug? Sort of. Design constraint would be a better
description, since the code is working as designed. What
the code didn't take into account was load that would be
placed on it by News.
Solution? Use UFS instead of AdvFS. The alternative is to
defragment the file system on a regular basis. If you don't
mind recreating the file system, you may also be able to set
the a parameter excessively high and then pre-create enough
empty files to handle the like future load.
AdvFS allocates per-file data structures dynamically. These
data structures are allocated from tables that are added in
large chunks of space (extents) which must be contiguous. The
number of such extents is also limited. Under the file creation/
deletion pattern created by news, the free space is quickly
fragmented and when a new extent needs to be allocated no
contiguous space can be found and no new files can be created.
Defragmentation will often free up enough space, but then you're
likely to hit the problem when the table reaches the limit on
number of extents.
When you create the initial domain or a new volume to it, you
can use the -x option to change the table extent size. Larger
extent sizes allow creating more files per extent. However,
that also makes it harder to find the necessary amount of
contiguous space should the table want to grow. It may seem
that using a smaller size allows finding contiguous space
more easily, the limit the number of extents prevents doing
it this way. Pre-creation of the necessary number of files
ensures that the space is available, but pretty throughly
sets the upperbound on number of files.
This has long been a problem with AdvFS and none of the
solutions are good ones. A good fix is clearly a hard
problem or one would have been provided by now. For News
UFS is still the better file system.
-------
Henrik Johansson
GlobeCom Network
Received on Mon Aug 26 1996 - 07:54:09 NZST