[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vmszoo::rms_openvms

Title:	RMS asks, 'R U Journaled?'

Moderator:	STAR::TSPEERUVEL

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 17: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 12: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 17:53`	4
	Thanks. That's two suggestions for using rms services and ru journaling. I'll make that suggestion to my customer. Jerry