Subject: | |
From: | |
Reply To: | |
Date: | Fri, 14 Aug 1998 15:20:47 -0500 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
> -----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.
|
|
|