I asked if anyone could explain why removing a cloned fileset,
specifically after using the clone to backup a heavily accessed
fileset, should take such a long time. Shouldn't it be just a
matter of resetting a couple of pointers and freeing some before-
image blocks?
Nobody gave a definitive answer, but I did get several insightful
replies.
It appears that rmfset's running time may be related to the
number of files in the fileset, as well as, or even instead of,
the amount of write activity against the underlying fileset.
Alan_at_nabeth.cxo.dec.com points out that the timing doesn't
seem a lot different from doing an "rm -r" on the fileset, and
suggests that the algorithm may be something like this:
> foreach file in the fileset
> reset some pointers and free the
> before-image block
>
> Since it probably doesn't do the operation in bulk, each
> transaction has to be logged. With enough files, the log
> becomes full and some of it has to be flushed before more
> transactions can be logged.
>
> If this is what happens, then removing any fileset can be
> a very I/O intensive operation. If the log is at one end
> of the disk or the other and much at of the real metadata
> is at the other end, the I/O becomes seek intensive.
I also asked if I could reduce the total runing time of our backup
of several filesets by doing the rmfset's in background. David
Gelhar <david.gelhar_at_Dartmouth.edu> shared his experience with
doing rmfset's in the background:
> If you do the natural thing:
>
> clone fileset A; backup clone A; remove clone A <backgrounded>
>
> clone fileset B; ...
>
> it probably won't speed things up. In my experience, commands
> like clonefset and rmfset will appear to hang until the
> backgrounded rmfset completes. There appears to be some kind of
> locking in AdvFS so only one rmfset/clonefset command can be
> running at a time, even on different file domains.
>
> There might be some benefit to creating the clone of B (creating
> the clone is quick) *before* removing the clone of A in the
> background; I haven't tried that approach (seems a bit too
> complex).
Todd Acheson <acheson_at_ohiou.edu> sent this warning:
> Just a warning if you upgrade to 4.0D.
>
> With patch kit 003 there are some lock problems where an rmfset
> renders the whole domain inaccessible. this is a known problem
> that compaq is working on, but it sure ruined one of my mornings.
Thanks to everyone who replied:
David Wolinski <wolinski_at_umich.edu>
<alan_at_nabeth.cxo.dec.com>
Gernot Salzer <salzer_at_logic.at>
Todd Acheson <acheson_at_ohiou.edu>
David Gelhar <david.gelhar_at_dartmouth.edu>
--
-- Phil Rand <prand_at_spu.edu>, aka <postmaster_at_spu.edu>
-- http://www.spu.edu/users/prand (206) 281-2428
-- Computer and Information Systems
-- Seattle Pacific University
-- 3307 3rd Ave. W., Seattle, WA 98119
------------------------------------------------------------------------
"One person CAN change the world, but most of the time,
you probably shouldn't." -- Marge Simpson
Received on Wed Mar 03 1999 - 18:34:23 NZDT