Article View: bit.listserv.l-vmctr
Article #756Re: DASD recovery.
From: Richard W Wiggins
Date: Fri, 24 Jan 1992 13:34
Date: Fri, 24 Jan 1992 13:34
45 lines
3151 bytes
3151 bytes
>..................... I'm trying to figure out a way to get back disk >space from users who aren't using what they've been allocated. >I see lots of people in the VMRMUA report who have only one or two files >sitting on a minidisk that hasn't been updated in ages. > I have read in the archives of this list about how some sites have >this all fully automated... ie.. Professor X goes away for a long time. >His minidisk ages. A service machine sends his minidisk to tape after it >is idle for six months. A year later the good Professor logs on, he gets >a msg saying *ONE MOMENT PLEASE* as his minidisk is reallocated and >reloaded. I'm aware of three universities who've tackled this (Cornell, Princeton, and Ohio U); maybe someone from one of those sites could speak up. Especially under current releases, this should be relatively easy to do, with the System Profile looking up whether the user's 191 disk is on archive, and causing the disk to be restored if not. You would leave each user defined in the Directory but would archive and delete the minidisk when the aging threshold is hit. In the Unix world there is software called Unitree that intercepts opens to files and causes tape mounts to restore files that have been archived and deleted behind the user's back. If you combine this software with robot tape technology, you can be very aggressive about deleting files based on size and age. Only when an application seeks to open a file is an attempt made to restore it. With a robot tape drive the application might pause for a minute or so while the file is restored; once it's back, the application resumes. It would be wonderful to see this sort of model implemented in VM. Anyone who looks at a VMRMUA will see a shocking number of files that haven't been updated in eons. You'd have to have a last reference timestamp on files (not just last update) to do this right. The Shared File System may be the place to implement this. If you think about it, this sort of scheme could change the way we think about disk. Any large file that occupies disk but isn't used for more than a few days is a candidate for rolling off to tape -- assuming only a brief pause to restore it. Files that are mission critical could be exempted. You could provide the user with a true "virtual disk farm" as big as a terabyte, and possibly without adding a single disk drive. /Rich Wiggins Michigan State U
Technical Details
Message-ID:
<L-VMCTR%92012408470936@VM1.CC.UAKRON.EDU>Path:
arc1-ca.pugleaf.net!sparky!uunet!europa.asd.contel.com!paladin.american.edu!auvm!MSU.BITNET!RWWMAINTShow Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fe320,68d0d2789b94b42f X-Google-Attributes: gidfe320,public X-Google-ArrivalTime: 1992-01-24 06:04:36 PST Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Path: arc1-ca.pugleaf.net!sparky!uunet!europa.asd.contel.com!paladin.american.edu!auvm!MSU.BITNET!RWWMAINT Message-ID: <L-VMCTR%92012408470936@VM1.CC.UAKRON.EDU> Newsgroups: bit.listserv.l-vmctr Date: Fri, 24 Jan 1992 08:34:39 EST Sender: VMCENTER Components Discussion List <L-VMCTR@AKRONVM.BITNET> From: Richard W Wiggins <RWWMAINT@MSU.BITNET> Subject: Re: DASD recovery. In-Reply-To: Message of Thu, 23 Jan 1992 17:44:06 CST from <STOODT@NUACVM>