From: Foti Gergely EB_HU (FotiG@erstebank.com)
Date: Tue Aug 19 2003 - 05:49:23 EDT
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.
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:32 EDT