[OpenAFS] script to control garbage
David Bear
David.Bear@asu.edu
Mon, 4 Aug 2008 13:35:47 -0700
------=_Part_28666_10326646.1217882147111
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On 8/4/08, Bryan Howard <bryan@alumni.caltech.edu> wrote:
>
> systems@bii.a-star.edu.sg wrote:
> > if n is 10 days
> >
> > find /myvolume -mtime +10 -exec mv {} /myarchive \;
>
>
> That seems a bit over-simplified. I think most folks would be
> surprised when whole directory trees suddenly got moved to the
> archive even though files within those trees had changed recently.
>
> At *least* give them this:
>
> find /myvolume -type f -mtime +10 -exec mv {} /myarchive \;
>
>
> Then we should probably at least mention that find can be a real
> problem in AFS space due to the possibility of volume mounting loops.
> Since *users* can make volume mount points, this is actually quite
> likely. You'll need to build a custom find executable which
> understands AFS mount points and keeps track of which volumes it's
> already traversed.
Yes indeeed. The point of my original post though was to see if mtime was
reliable as I thought I recall hearing at the openafs best practices that
atime=mtime=ctime.
If others are using mtime to select files for age (last modified date)
successfully, then it may be safe.
what I really want is a reliable atime. Then I would know what files really
are dead.
Is there anyway to prevent standard afs processes like vos dump, vos backup,
etc. from changing atime?
{Bryan}
>
> --
> Bryan D Howard
>
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
--
David Bear
College of Public Programs at ASU
602-464-0424
------=_Part_28666_10326646.1217882147111
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<br><br><div><span class="gmail_quote">On 8/4/08, <b class="gmail_sendername">Bryan Howard</b> <<a href="mailto:bryan@alumni.caltech.edu">bryan@alumni.caltech.edu</a>> wrote:</span><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
<a href="mailto:systems@bii.a-star.edu.sg">systems@bii.a-star.edu.sg</a> wrote:<br> > if n is 10 days<br> ><br> > find /myvolume -mtime +10 -exec mv {} /myarchive \;<br><br><br>That seems a bit over-simplified. I think most folks would be<br>
surprised when whole directory trees suddenly got moved to the<br> archive even though files within those trees had changed recently.<br><br> At *least* give them this:<br><br> find /myvolume -type f -mtime +10 -exec mv {} /myarchive \;<br>
<br><br> Then we should probably at least mention that find can be a real<br> problem in AFS space due to the possibility of volume mounting loops.<br> Since *users* can make volume mount points, this is actually quite<br>
likely. You'll need to build a custom find executable which<br> understands AFS mount points and keeps track of which volumes it's<br> already traversed.</blockquote><div><br> </div>Yes indeeed. The point of my original post though was to see if mtime was reliable as I thought I recall hearing at the openafs best practices that atime=mtime=ctime. <div>
<br>If others are using mtime to select files for age (last modified date) successfully, then it may be safe.<br><br>what I really want is a reliable atime. Then I would know what files really are dead.<br><br>Is there anyway to prevent standard afs processes like vos dump, vos backup, etc. from changing atime?<br>
</div><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
{Bryan}<br><br>--<br> Bryan D Howard<br><br><br> _______________________________________________<br> OpenAFS-info mailing list<br> <a href="mailto:OpenAFS-info@openafs.org">OpenAFS-info@openafs.org</a><br> <a href="https://lists.openafs.org/mailman/listinfo/openafs-info">https://lists.openafs.org/mailman/listinfo/openafs-info</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>David Bear<br>College of Public Programs at ASU<br>602-464-0424
------=_Part_28666_10326646.1217882147111--