Thanks to:
john_jorgensen_at_wsu.edu
"Jan D'Addamio" <daddamio_at_zso.dec.com>
Mike D Cross <crossmd_at_mh.uk.sbphrd.com>
for their replies.
===========================================
Most advice I received was vdump, remove the file domain, make the file domain
and vrestore, which is what I have done. (Performace is much improved :-)
>From Jan D'Addamio of AdvFS Development, Compaq Computer Corp. (formerly
Digital Equipment Corp.) I got the following
>The problem was definitely caused by trying to defragment one of the very
>large files you had. One of the people I work with has just developed a fix
>for this. If you need more details as to why it happened, I can see if he can
>provide them to you. The fix will definitely be in V5.0. I don't know if it
>can be backported to older releases or not, but one way for you to find out is
>to have your support person file an IPMT on your log half full problem.
>
> If you had a lot of files on your domain, verify could very well run
>out of memory. In that case, it does what it can without the memory.
>It's have to say exactly what the cause was because you didn't specify
>any output. You probably would have been better off if you just restored
>the domain at that point. If you can still mount it, I would say do a
>backup, wipe out the domain, and restore. If you can't mount it, we have
>a new utility called salvage which will be able to get the files off if
>you don't have a good backup. Your support person can get a copy for you
>if you really need it.
So I have and nice new file domain. Now my verify still gives out of
memory problems. I search the archives and found acheson_at_ohiou.edu:
>When things started to settle down with the hardware (replacement of a
>storage works shelf and personality module) , we pursued the verify
>issue and were told that it couldn't handle large domains, but that if
>vdump/vrestore didn't have any errors then the domain/filesets were OK.
and john_jorgensen said:
>Addressing the issue of "out of memory", we have also experienced that
>and had to issue the following commands in sh
>
> ulimit -S -d 1048576
> ulimit -S -s 32768
>
>or in ksh
>
> ulimit -S -d unlimited
> ulimit -S -s unlimited
Which I haven't tried yet.
My original post was:
>Advfs questions.
>
>Hi
>
>I after a bit of advice regrading advfs, esp in regrad to
>defragmentation.
>
>I have a AlphaServer 1000 4/266 running DU 4.0b with patches
>duv40bas00006-19971216. It has an 20GB advfs on a raid 5 system.
>The advfs was created under 3.2c (I think).
>
>I believe that the advfs has never been defragmented. When the system
>was running 3.2c "I ran defragment -nv" - I dont still have the output
>but I remember something like "io eff 43%". I remember that this
>command took a very long time to compleate (> 2hours).
>
>I took the system down to single user mode and tried to defragment.
>The system crashed with the following written into the binary error
>log:
>
>panic (cpu 0): release_dirty_pg: log_half full
>
>I have spoken to digital about this who told me to increase the log
>size by adding a volume to the advfs, moving the log to the new
>volume and trying again. I have the spare partition I have also
>removed some very large (> 1.5GB) files from the systems (Networker's
>index files) that would be prime candidates for fragmentation.
>
>I tried to verify the advfs but got some out of memory messages and
>nothing seemed to happen. In the end I had to bring the system up
>without being able to verify. [the advfs is suppose to fix itself
>after a crash, right?]
>
>Q: Should I try to defrag, or should I backup, wipe the advfs out,
>created it again and restore?
>
>Q: Why did the verify fail? (this was before I moved the big files)
>
>TIA
--
Bevan Broun ph (08) 9380 1587
Computer Systems Officer fax (08) 9380 1065
Dept. Electrical and Electronic Engineering
University of Western Australia rm. G70
Received on Mon Jul 20 1998 - 10:30:36 NZST