FINAL SUMMARY: error during rmvol

From: Foti Gergely EB_HU (FotiG_at_erstebank.com)
Date: 08/19/03

  • Next message: Himanshu Khona: "Hardware diagnostics" 
    Date: Tue, 19 Aug 2003 11:49:23 +0200
To: tru64-unix-managers@ornl.gov

    It's just for info!

    As I tried to fix the domain with /sbin/verify the machine crashed. The domain must had been removed. The analysis found out, that I had an AdvFS bug, fixed in pk6.

    -----Original Message-----
    From: Foti Gergely EB_HU [mailto:FotiG@erstebank.com]
    Sent: 2003. augusztus 11. 13:49
    To: tru64-unix-managers@ornl.gov
    Subject: SUMMARY: error during rmvol
    Importance: Low

    Hi,

    Thanks all for help, especially Dr. Thomas Blinn! (Excuse me about that, we use Tru64 UNIX 5.1 on GS140, with pk5)

    I didn't really tune metadata cells because this fs contains only a few files (maybe 6 files). The defragment did not help, neither adding additional disks, and then remove the stucked one. The forced removal also failed with the same message, so I will destroy this domain when I find some free space.

    Fóti, Gergely

    -----Original Message-----
    From: Dr Thomas.Blinn@HP.com [mailto:tpb@doctor.zk3.dec.com]
    Sent: 2003. augusztus 11. 13:02
    To: Foti Gergely EB_HU
    Subject: Re: error during rmvol appendix

    This isn't about open files or file data, it's totally about some AdvFS
    internal data that's run out.

    I'd have to go read AdvFS code to be 100% sure, but I have been through
    the AdvFS internals training. "MCELLS" are metadata cells, I believe
    you allocate the number and extent size for them when you create the
    domain initially, in this case you added a volume later and you are
    now trying to remove it, that means all the data structures on the
    added volume need to be moved to other volumes, and presumably there
    are not enough of these metadata cells on that first volume, so you
    get this failure. I trust you have read the AdvFS reference pages to
    see if you can figure out how to create more metadata cells or how to
    compact their use. It is remotely possible that you can fix this by
    adding yet another volume with more metadata resources, forcing the
    removal of the other two volumes (the added one and the original), and
    then things will be copacetic. It's also possible that if you defrag
    the domain things will then work. The SIMPLEST thing by far is to
    create a new domain, move the data to it, then destroy the old domain.

    Oh, by the way, you NEVER said what version of Tru64 UNIX or whether
    if it's V5.x this is a new format or old format domain; there were a
    lot of problems like this in the old AdvFS implementation on V4.x
    that were supposed to have been fixed in V5.x.

    Tom

    > Hy all again,
    >
    > First thanks to all, who replied!
    >
    > I deleted almost the whole content of the file domain, even fuser said
    > that I haven't got any open files and I still have this problem. I
    > don't like to remove the file domain (if it's avoidable), because it's
    > an archivelog domain for Oracle.
    >
    > Do someone know properly what is ENO_MORE_MCELLS (-1055)?
    >
    > Thanks a lot!
    > F=F3ti, Gergely
    >
    >
    > >Hi all,
    >
    > > Do you know what's this error message about? What should i do to
    > remove that partition from the domain? There's only one fileset, and
    > seems like still something located on dsk701h.
    >
    > > This isn't that urgent, i won't work with it until monday.
    >
    > > unix# rmvol /dev/disk/dsk701h dom01
    > > rmvol: Removing volume '/dev/disk/dsk701h' from domain 'dom01'
    > > rmvol: Can't remove the volume
    > > rmvol: Error = ENO_MORE_MCELLS (-1055)
    > > rmvol: Can't remove volume '/dev/disk/dsk701h' from domain 'dom01'
    >
    > > the showfdmn says:
    > > unix# showfdmn dom01
    >
    > > Id Date Created LogPgs Version Domain
    > Name
    > > 3daa415e.020378d4 Mon Oct 14 06:00:30 2002 512 4 dom01
    >
    > > Vol 512-Blks Free % Used Cmode Rblks Wblks Vol Name
    > > 1L 70983536 65643568 8% on 256 256
    > /dev/disk/dsk219d
    > > 2 35369392 35364640 0% on 256 256
    > /dev/disk/dsk701h
    > > ---------- ---------- ------
    > > 106352928 101008208 5%
    >
    > > Thanks!
    >
    > > F=F3ti, Gergely
    >

    Tom

       Dr. Thomas P. Blinn + Tru64 UNIX Software + Hewlett-Packard Company
     Internet: tpb@zk3.dec.com, thomas.blinn@compaq.com, thomas.blinn@hp.com
      110 Spit Brook Road, MS ZKO3-2/W17 Nashua, New Hampshire 03062-2698
       Alpha Hardware Platforms and I/O Phone: (603) 884-0646
         ACM Member: tpblinn@acm.org PC@Home: tom@felines.mv.net

      Worry kills more people than work because more people worry than work.

          Keep your stick on the ice. -- Steve Smith ("Red Green")

         My favorite palindrome is: Satan, oscillate my metallic sonatas.
                                    -- Phil Agre, pagre@alpha.oac.ucla.edu

         Yesterday it worked / Today it is not working / UNIX is like that
                            -- apologies to Margaret Segall

      Opinions expressed herein are my own, and do not necessarily represent
      those of my employer or anyone else, living or dead, real or imagined.
     

  • Next message: Himanshu Khona: "Hardware diagnostics"