On Oct 31, 7:53pm, Chris Cowan wrote:
> > I'd like to evaluate the merits of this approach, especially I need
> > to know how many volumes out there are not accessed. The
> > "vos examine" command gives the last update time but not the last
> > access time to account for reads. I tried the volinfo command on file
> > servers and it always gives a zero "accessDate". I guess it is not really
> > used. It also gives a "dayUseDate". Would it be an accurate reference
> > for the last access date???
>
> I would highly advise that you look at AFS and DFS as separate entities.
> One of the more notable differences is that unlike AFS, DFS does a
> better
> job with metadata, particularly things like atime, mtime, ctime. (It
> would not be
> able to deliver POSIX single site semantics, if it didn't)
Yes, Craig Everhart also mentioned to me earlier that DFS maintains the
"per-file" access time, and suggested that looking at the accees time of the
root directory would probably be useful to determine whether a fileset has not
been accessed for a real long time. I am not sure how safe this would be.
Would a client cache a non-changing root directory forever, and continue
accessing other portions of the fileset?
I do think it is very important to have the last access time of volume/fileset
added to AFS/DFS. It is not really a difficult thing to do, and it could help
manage the storage cost a lot!
> Please do not limit the function of your system to what you empirically
> observe with
> AFS. Look at DFS, too!!!
I am not limitting the scope to AFS. But I think I might get more statistics
from AFS than DFS, and I think DFS will have the same access paterns
eventually.
> > It is also a concern that some file backup, garbage collection, or
> > virus checking programs might access these inactive volumes periodically,
> > and make them look accessed. So, any volume access time reading may not
> > be accurate in these environments.
>
> It shouldn't be too difficult to work around some of this. Does it
> really matter
> whether there are anywhere from 1-10 accesses to a volume or fileset,
> when others are
> getting hit 1000's of times. If you loooked a statistical distribution
> of the volume access,
> it should be easy to ascertain a baseline for the adminstrative
> overhead.
Depending on what kind of nearline approach we are looking at, whether there
are 1-10 "useful" accesses might be important. If a volume/fileset is not
accessed at all other than the backup or virun-checking ones, they can be moved
to tapes. Otherwise, they should probably stay on optical library at least.
I think the backup and virus checking type of programs should be turned off
for the filesets that are not modified. The modification time of the volumes
are available thought "vos examine" or "fts lsft".
> > Has this kind of measurement being done? How did you do it? What
> > did you find? Do you think space management based on volumes might be
> > useful to you?
>
> Yes, it was done at the IBM Austin site. I'm sure it's been done at
> other
> places.
Did you move the volumes off the VLDB or you just moved the volumes to slower
disk-like devices? We are looking at an order-of-magnitude cost differece
between optical disks and tapes. If a significant number of volumes are not
acceessed at all, some tape solution should be considered, IMHO.
Shyh-Wei
> Regardless of the technique, volume (or fileset) archival and management
> is
> sorely needed. At Decorum it is probably one of the most frequently
> requested items from
> the file system user community.
>
>
> --
> Chris Cowan PSW Technologies
> [EMAIL PROTECTED] Distributed Computing Systems
> (512) 343-6666 x339 9050 Capital of Texas Hwy. North
> (512) 345-4976 (fax) Austin, TX 78759
> http://www.pswtech.com
>-- End of excerpt from Chris Cowan
