[OpenAFS] Removing a backup volume
Derrick Brashear
shadow@gmail.com
Mon, 25 Jun 2007 09:34:12 -0400
------=_Part_2284_12714506.1182778452711
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On 6/25/07, Steven Jenkins <steven.jenkins@gmail.com> wrote:
>
>
>
> On 6/18/07, Frank Burkhardt <fbo2@gmx.net> wrote:
> >
> > Hi,
> >
> > I'm currently removing a backup clone which belongs to a volume
> > containing ~
> > 55 GB in ~ 102000 files. 'vos status' shows a "DeleteVolume" transaction
> > which is running since 63 min now.
> >
> > Is it supposed to take that long? I've seen this on all of our file
> > servers
> > - especially when performing clone operations (e.g. vos backup, vos
> > release). However: cpus are ~99.5% idle (cpu load is always ~1.0 ). The
> > fileserver removes the clone exclusively - noone else accesses content
> > from
> > the volume's volumegroup and it's the only volume on the server.
> >
> > Is there a way to speed things up?
> >
>
> My understanding (as this problem was described to me last week) is that
> this is 'normal' and 'expected'. It's certainly not optimal. There are no
> simple suggestions I know of that will speed up these operations; however,
> there have been some discussions around how to speed this up.
The root problem here is the underlying filesystem presumably offers poor
performance for deleting files, and the way to fix it is to use a filesystem
that doesn't. Deleting a volume is really deleting a tree of files and
directories, and it won't run any faster for OpenAFS than it does for
anything else.
What's the problem, exactly? Impatience or is there an actual operational
issue?
Derrick
------=_Part_2284_12714506.1182778452711
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<br><br><div><span class="gmail_quote">On 6/25/07, <b class="gmail_sendername">Steven Jenkins</b> <<a href="mailto:steven.jenkins@gmail.com">steven.jenkins@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div><span class="gmail_quote">On 6/18/07, <b class="gmail_sendername">Frank Burkhardt</b> <<a href="mailto:fbo2@gmx.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">fbo2@gmx.net</a>> wrote:
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br><br>I'm currently removing a backup clone which belongs to a volume containing ~<br>55 GB in ~ 102000 files. 'vos status' shows a "DeleteVolume" transaction<br>which is running since 63 min now.
<br><br>Is it supposed to take that long? I've seen this on all of our file servers<br>- especially when performing clone operations (e.g. vos backup, vos<br>release). However: cpus are ~99.5% idle (cpu load is always ~1.0 ). The
<br>fileserver removes the clone exclusively - noone else accesses content from<br>the volume's volumegroup and it's the only volume on the server.<br><br>Is there a way to speed things up?<br></blockquote></div>
<br>
My understanding (as this problem was described to me last week) is that this is 'normal' and 'expected'. It's certainly not optimal. There are no simple suggestions I know of that will speed up these operations; however, there have been some discussions around how to speed this up.
</blockquote><div><br><br>The root problem here is the underlying filesystem presumably offers poor performance for deleting files, and the way to fix it is to use a filesystem that doesn't. Deleting a volume is really deleting a tree of files and directories, and it won't run any faster for OpenAFS than it does for anything else.
<br></div></div><br>What's the problem, exactly? Impatience or is there an actual operational issue?<br><br>Derrick<br><br>
------=_Part_2284_12714506.1182778452711--