Post by JF MezeiPost by John SantosYou will probably still end up with the EOF pointing to the beginning of
the file (directory shows 0/xxx for the size), but BACKUP should copy
whatever has actually been written to the disk
Can anyone confirm this ?
I can't confirm this; this is based on behavior of backup with files
where the EOF pointer can't be trusted, i.e. indexed files.
Post by JF MezeiIf I have a file that is 0/432 blocks, and I use
backup/ignore=interlock, how does BACKUP know how many blocks have been
written ?
It doesn't know or care. It can copy the entire allocated space, which
is what it does with indexed sequential files. (Unless you say
/truncate, so don't do that!)
If it forces a flush to disk, wouldn't that cause the
Post by JF Mezeiblocks/used count to increase after the backup completes ?
A flush of what to what disk? Of the original data file to the input
disk? No. If the program hasn't written the data to the disk, it isn't
there for Backup to see.
Of course Backup flushes all its output to the output disk.
Post by JF MezeiIf i start a new file and start writing data with the C runtime with no
special options, (eg: no ctx=rec ) and no flushes/fsync, at what point
does the blocks/used displayed by dir get updated ?
This is almost certainly irrelevant to the original poster. He had
a log file (possibly a process created with run/detach/output=...)
that wasn't opened with "allow read" or "SHR=GET" or whatever the
language equivalent. We don't know what language was use to write
the program, no on has said "C".
But writing to the disk and updating the file attributes are
entirely separate operations. There is no guarantee that anything
useful has been written to the log yet, but is certainly possible.
The log, IIRC was several hundred blocks long, so quite likely the
program has been writing it to disk (and extending it as it goes),
but hasn't updated the attributes and won't until it closes the
file. The default behavior of RMS with regards to flushing data
and writing attributes depends on the sharing options used. Since
apparently no sharing was defined for the file, it saves the overhead
of re-writing the attributes until it has to, i.e. when the file is
closed. However, it probably writes data to the disk when ever its
internal buffer gets filled, probably determined by RMS Multi-Block
count, unless it has been overridden by the program.
Post by JF MezeiWhile the program is running, I assume that the file system has a local
copy in memory of the blocks used that increases as I do my fprintfs,
but is that value accessible by other processes ? Does this get written
to dick from time to time, or only opnce the file is closed ?
And more importantly, if there is a power failure after I have written
100 blocks. When the system reboots, how does it know that 100 blocks
have been written if, at the time of the failure, dir/zize=all still
showed 0 blocks used ?
Well, there is also highwater marking (if enabled), but it doesn't know
that valid data has been written to the blocks between the EOF and the
highwater mark, just that all the blocks have either been written by
the program or by the highwater-marking zeroing routine, so they are
safe from scavenging.
Post by JF Mezei(does the set volume/rebuild go though the file to find an end of file
market and then update the blocks used ?)
No. SET VOLUME/REBUILD has nothing to do with this; it fixes extent
and file header allocation caches. (These are free extents and headers
pre-allocated to a system so it doesn't have to go through all the
hand-shaking every time a file is created or extended. That can be
a lot of overhead, especially on a cluster, so instead of allocating
them one-at-a-time, each system grabs a bunch and uses them until it
runs out, then grabs a bunch more. I think it uses a door-bell lock
to get other nodes to release some of their caches if an allocation
fails, so this is generally invisible to the cluster but a lot more
efficient. Locks are really cool, but work best when you don't use
them :-) :-)
The logical place for something like that would be analyze/disk/repair,
but there are too many cases where this would be the disastrously
wrong thing to do. Anyway, there are no embedded EOFs in most data
files; EOF is determined by the attributes (or for ISAM files, by
following the bucket links until you get to the end.) I suppose
there might be a ctrl/Z or a <nul> at the end of a STREAM_* file,
and there are cases of a -1 length byte in SEQUENTIAL VARIABLE
files, but these aren't necessarily present, and if you find one,
it might be noise.
--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539