I understand Stan's desire to save the user from :STORE'ing data that
need not be :STORE'd, but I'd say that if he wants data to stay
around, he should put it inside the EOF.
"Philosophically", nothing exists beyond the EOF.
Some might argue that this "problem" is an indication that MPE should
have a shared memory facility beyond mapped files, but I would reply
that one can exclude your shared memory files from a :STORE using
capabilities that :STORE already has.
I think it's neat that mapped files serve so well as shared memory.
Jim
> Date: Fri, 14 Aug 1998 10:09:05 -0700
> Reply-to: Stan Sieler <[log in to unmask]>
> From: Stan Sieler <[log in to unmask]>
> Subject: Question: should XLTRIM affect files with EOF=0? (long)
> To: [log in to unmask]
> Hi all,
>
> I have a philosophical question about how the "XLTRIM" concept
> should work.
>
> Question:
>
> *Should* a utility program do an XLTRIM on a file whose EOF is 0?
>
> Background #1: Trimming
>
> On MPE V, MPE provided a method (via FCLOSE) to let a program
> release all sectors of a file that were "above" the EOF.
> MPEX, and others, provided users the ability to "TRIM" their
> files via this feature. The side-effect is that the LIMIT is
> reduced down to the current EOF.
>
> On MPE/iX, MPE still provides that feature, but it added a new
> feature. FCLOSE can let a program release all pages of a file
> that are "above" the EOF ... *without* changing the LIMIT.
> MPEX, and others, provided users the ability to "XLTRIM"
> their files via this feature.
>
> Background #2: Users
>
> On MPE/iX, users sometimes do "BUILD AXLDEV1;DEV=1;DISC=xxx,y,y"
> to fully allocate some disk storage for some reason (e.g., to
> ensure that they always have a certain amount of potentially free
> disk space available in the future). (Yes, Ken N., they do it
> on MPE V as well :)
>
> Background #3: Tools
>
> MPEX's XLTRIM will throw away that carefully reserved disk space.
>
> De-Frag/X's TRIM command will not throw it away ... we said "gee,
> if the EOF is exactly 0, then the disk space was manually allocated
> by the user for a reason ... let's preserve it;
> if the EOF is greater than 0, then the extra disk space beyond the
> EOF is probably wasted space ... let's trim it."
>
> Solution-Soft's trim command: unknown.
>
> STORE will not backup any pages "above" the EOF.
>
> Problem:
>
> We have some software that needed an inter-process communication
> area ... a mapped file seemed ideal. However, we didn't want the
> data to persist across a restart, and we would prefer to save the
> user the cost of storing the data during their backups.
>
> So...we said, hey...let's just do:
> build foo; rec=128,1,f,binary; disc=1024,2,2
> this builds a file of 1024 * 256 bytes, fully allocated on disk,
> whose EOF is 0 and whose LIMIT is 1024.
> Then, we HPFOPEN it (with long mapped access) and use it.
>
> Things are fine. Until a user does an MPEX ALTFILE FOO;XLTRIM
> (while the file is closed) ...that discards the pages beyond
> the EOF. Since the EOF is 0, that means the entire data area
> is gone. Poof.
>
> Solutions:
>
> 1) we change our code to set the EOF to the LIMIT.
>
> This works, of course.
>
> Drawback: STORE will now backup the entire file :(
>
> Drawback: other users' use of BUILD to preserve disk space
> isn't free from harm from XLTRIM.
>
> 2) we convince Vesoft (and anyone else implementing XLTRIM)
> that files with EOF = 0 are special, and shouldn't be trimmed.
>
> Drawback: we still have to do a workaround, because it takes
> time for such changes to get distributed to all users.
>
> Thanks!
>
> --
> Stan Sieler [log in to unmask]
> http://www.allegro.com/sieler.html
>
Jim Kramer /Lund Performance Solutions
Director of Research and Development
phone: (541) 926-3800 fax: (541) 926-7723
email: [log in to unmask] home: [log in to unmask]
http://www.lund.com
|
