This message has been sent to both the tru64-unix-managers' mailing list
and the comp.unix.tru64 newsgroup. A summary of responses will be sent
in the (hopefully) near future, again to both forums.
I have a DS-10, with Tru64 Unix 4.0g on it, with AdvFS file systems.
One filesystem, designated "public", is expected to contain a very large
number of mostly small files. While data were being copied to it from
another system (with no AdvFS), I began to receive "No space left on
device" errors while attempting to create new files and directories.
df reports that I am not out of space (or out of inodes) on the
filesystem (Sorry about the long lines):
# df -ik
Filesystem 1024-blocks Used Available Capacity Iused Ifree %Iused Mounted on
public#public 5483080 3114465 1561824 67% 1228265 6619264 16% /public
public#pub-dev 32 16 16 51% 3 29 9% /public/dev
If I attempt to create a new fileset on the domain, I get the following
error:
# mkfset public foo
mkfset: can't create file set 'foo' in domain 'public'
mkfset: error = ENO_MORE_BLKS (-1040)
A check with the defragment utility, to see if perhaps the file domain is
fragmented shows:
# defragment -nv public
defragment: Gathering data for domain 'public'
Current domain data:
Extents: 226093
Files w/extents: 219518
Avg exts per file w/exts: 1.03
Aggregate I/O perf: 98%
Free space fragments: 46942
<100K <1M <10M >10M
Free space: 82% 18% 0% 0%
Fragments: 45002 1940 0 0
Looks pretty good, but let's see if we can't prehaps gain anything by
defragmenting:
# date; defragment -V public; date
Thu Aug 24 12:24:37 EDT 2000
defragment: Defragmenting domain 'public'
Pass 1; Clearing
Volume 1: area at block 6261936 ( 357264 blocks): 60% full
defragment: Moving file <unknown> (setTag: 3.32769 (0x3.0x8001), tag: 1.32769
(0x1.0x8001))
page offset: 31344, page count: 48
defragment: Can't move file <unknown> (setTag: 3.32769 (0x3.0x8001), tag:
1.32769 (0x1.0x8001))
defragment: Error = ENO_MORE_MCELLS (-1055)
defragment: Can't defragment domain 'public'
Thu Aug 24 12:24:38 EDT 2000
I'm aware that I can reserve space for the "Bitfile Metadata Table" at
the time I create the file domain, but the mkfdmn manual page suggests
that doing so is no longer necessary as the operating system handles
that internally:
With this version of the operating system you do not need the
-x num_pages and -p num_pages options. Users should plan to
migrate away from the use of these options. These options
were necessary in previous releases to allocate contiguous
storage for bitfile metadata table (BMT) operations. In this
release, storage for BMT operations is managed internally by
the operating system. This information is included for the
purpose of completeness.
Well, I noted that, and now I'm unable to use all the space on my file
domain. Nice. :-(
Does anyone know if it would be possible for me to recover from this
condition without rebuilding the file domain from scratch? (If I have
to rebuild it, I'm going to use UFS, of course -- AdvFS may not be quite
ready for prime-time...)
--
----------------------------------------------------------------------
Sylvain Robitaille syl_at_alcor.concordia.ca
Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------
Received on Thu Aug 24 2000 - 18:16:27 NZST