SUMMARY: DU-4.0G, AdvFS domain out of mcells. Suggestions?

From: Sylvain Robitaille <syl_at_alcor.concordia.ca>
Date: Thu, 24 Aug 2000 16:48:52 -0400 (EDT)

This message has been sent to both the tru64-unix-managers' mailing list
and the comp.unix.tru64 newsgroup. This is a summary of the responses
I've gotten to my original message, quoted below my signature.

First, an additional bit of information, which I neglected to include in
my original message. I received one suggestion that the df report may
be unreliable, and that showfdmn would show more accurately how much
space is used on the disk:

  # showfdmn public
  
                 Id Date Created LogPgs Domain Name
  3999c285.000ac796 Tue Aug 15 18:21:57 2000 512 public
  
    Vol 512-Blks Free % Used Cmode Rblks Wblks Vol Name
     1L 10966164 3123648 72% on 256 256 /dev/rz24f

I had checked that, actually and found it to be pretty consistent with
the df report:

  # df /public
  Filesystem 512-blocks Used Available Capacity Mounted on
  public#public 10966160 6228930 3123648 67% /public

It's always useful to get a second opinion, of course, so both reports
should be consulted. I haven't seen any reason not to believe df (and I
have been managing a number of DEC/Compaq systems for several years),
but I did want to mention that it's useful to consult showfdmn when what
you're seeing from df doesn't coincide with what the system is telling
you.

I received a couple of suggestions (from William Bochnik and Steven
Hancock), in response to my question about recovering from this
condition without rebuilding the file domain. They both suggested that
I could add a new volume to the domain, with appropriate "-x" and "-p"
parameters, then remove the existing volume, and the result would be a
file domain with more BMT space.

Very useful to know. This particular system currently has only one
disk, and no enclosure within which I can add any disks (it's a DS10),
so I'm probably just going to break-down and rebuild the file domain
from scratch, though. :-(

Both these fellows also took the time to remind me that UFS also has its
limitations, with respect to maximum number of inodes. Additionally the
time it would take to fsck a file system with such a large number of
files, in the event of a system or disk failure, is likely to be a
nuissance. They're right, of course. UFS is more familiar though, and
we (probably) all know how to deal with its limitations.

The problem here wasn't really with AdvFS, which for the record, I do
use extensively on my systems, usually with no problems, but rather with
the documentation in the mkfdmn manual page, which is somewhat
misleading. Steven Hancock tells me that the AdvFS in v5.x of the
operating system has significant improvements with respect to the BMT,
and that at that version of the OS, I *really* don't need to take its
size into consideration when I create the file domain.

I'm going to include a plug here, since he sent me an excerpt which I
found very useful, for Steven Hancock's book, "Tru64 UNIX File System
Administration Handbook", due out in October from Digital Press. The
excerpt is a section which discusses exactly what I experienced here,
"BMT exhaustion", how to prevent it, and how to deal with it when it has
happened. If the rest of the book is as informative, it's certainly
going to be worth keeping an eye out for.

Thanks all for your informative and prompt replies. I appreciate the
help.

-- 
----------------------------------------------------------------------
Sylvain Robitaille                              syl_at_alcor.concordia.ca
 
Systems analyst                                   Concordia University
Instructional & Information Technology        Montreal, Quebec, Canada
----------------------------------------------------------------------
On Thu, 24 Aug 2000, I wrote:
> 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...)
> 
> 

Received on Thu Aug 24 2000 - 20:50:10 NZST