[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | RMS asks, 'R U Journaled?' |
|
| Moderator: | STAR::TSPEER UVEL |
|
| Created: | Tue Mar 11 1986 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3031 |
| Total number of notes: | 12302 |
3012.0. "partial writes?" by CSC32::J_HENSON (Don't get even, get ahead!) Tue Feb 18 1997 14:20
OpenVMS for Vax V6.1
I have sort of a strange question. I'm hoping that someone can give
me a not-so-strange answer. This question has been asked by a
customer, so I do need to get an answer. Also, it was asked in
terms of the Dec C RTL, and I have posted note 2095 in turris::decc
asking this. However, it's also an RMS question, so I want to
get some feedback from this conference.
My customer is concerned about what happens when she writes a record
to a nearly full disk, and there is not room on the disk for the
entire record/write. Her objective is to do this in such a way
that either the entire write goes to disk, or none of it does.
Her testing has shown that if she writes a stream_lf file, in C
"stream" mode, she will get a partial write. That is, if she
attempts to write a 2k buffer, and there's only 1k of space
available, the write fails but she gets the 1st 1k of the buffer
written to disk.
She further claims that if she writes a variable record length file,
and encounters the same situation, the write still fails but none
of the buffer gets written to disk. This is the behavior she wants,
but she doesn't completely trust her results and wants confirmation
from Digital that this is the way it's supposed to work.
I don't know the answer, as I've never encountered this before, nor
can I find any documentation that specifically addresses this. So,
can someone tell me the rules that RMS uses when trying to write
a buffer to disk that is larger than the available space on the
disk?
Thanks,
Jerry
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3012.1 | RMS RU Journaling | STAR::EWOODS | | Wed Feb 19 1997 09:17 | 34 |
|
<<My customer is concerned about what happens when she writes a record
<<to a nearly full disk, and there is not room on the disk for the
<<entire record/write. Her objective is to do this in such a way
<<that either the entire write goes to disk, or none of it does.
If she is looking for a guaranteed way, then point her to RMS RU
journaling. She really is asking how data consistency can be
ensured and how she can recover when there has been a disaster (her
example is a nearly full disk).
If the application isn't important enough to use journaling, then
time would be better spent at a system level ensuring sufficient disk
space for all applications on the system.
Her simple comparisons are not based on direct calls to RMS services
by the application. Her I/O is being done by the C RTL. Her comparison
is between "stream access" through C RTL to a stream-lf record and a
C RTL non-stream access to a variable record. C RTL handles the two
differently in terms of the RMS calls they generate. My understanding
is that C RTL stream mode uses RMS block I/O calls ($READ and $WRITE),
which doesn't have a notion of a "record." It is just a stream of
bytes. For the variable record, C RTL uses RMS record I/O call
($PUT). In other words, she is comparing apples and oranges.
In general a $PUT to a sequential file (presumed since stream can only be
used with sequential) will fail in circumstance she describes, but since
we are talking about what should be a rare and unusual circumstance (from
my perspective, a disaster scenario), things get unpredictable and I certainly
would not be willing to give a 100% guarantee that either entire record goes
to disk or none. That is one of the reasons that applications use RMS RU
journaling.
-- Elinor
|
| 3012.2 | Thanks | CSC32::J_HENSON | Don't get even, get ahead! | Wed Feb 19 1997 14:53 | 4 |
| Thanks. That's two suggestions for using rms services and ru journaling.
I'll make that suggestion to my customer.
Jerry
|