🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: bit.listserv.l-vmctr
Article #756

Re: DASD recovery.

#756
From: Richard W Wiggins
Date: Fri, 24 Jan 1992 13:34
45 lines
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!RWWMAINT

Show 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>