HP3000-L Archives

August 1998, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Scott McClellan <[log in to unmask]>
Reply To:
Scott McClellan <[log in to unmask]>
Date:
Fri, 14 Aug 1998 15:20:47 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (56 lines)
> -----Original Message-----
> From: HP-3000 Systems Discussion [mailto:[log in to unmask]]On
> Behalf Of Stan Sieler
> Sent: Friday, August 14, 1998 12:09 PM
> To: [log in to unmask]
> Subject: Question: should XLTRIM affect files with EOF=0? (long)

[stuff deleted...]
> 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 :)
I tend to agree with Bruce's comment with regard to the "OS not
expecting
anything important beyond EOF...". I don't know of any planned OS
enhnacement
that would break this, but I would not rule it out given making use of
this
"feature" would not be anticipated (necessarily).


[stuff deleted...]
> 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 :(
Why not just set the "do not store" bit in the file label?
Then STORE will never store the file (which would seem to be
what you want).

>      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.
Given your comment, it appears that convincing "everyone" (whoever
"everyone" is) to change is not a solution to your problem. It
may be a good idea, but it does not protect your file until it is
implemented.

I guess I tend to see some merit in the rule you put into your product
but what about the case where the file just "shrank" and now the EOF
is ZERO (like a message file that was very full, but now happens to be
empty). I would think that XLTRIM should trim that file. Basically,
I think your rule is "safer" but I also think that you can't tell
for sure whether or not a file should be trimmed just by looking
at the EOF.

ATOM RSS1 RSS2