full mount point detection (A500)

[Bill_14]

Hi,

I have a strange situation. My application is checking the return value from fwrite to verify that a write to disk was successful. On D and R servers, it works fine. However, running the same code on an A500 server, the mount can fill up, but the application does not recognize that there is a problem. All of this is occuring running HPUX 11.00.


Suggestions?

[harry d brown jr]

Is your D, R, and A running 11.00/64?

Are the compared logical volumes identical in setup?

Do all of the servers have the same patch levels?


live free or die
harry

[A. Clay Stephenson]

Hi Bill:

I'm guessing that your D & R boxes are running 32-bit and you A box is running 64-bit.

I assume that you mean fwrite is returning the expected number of items written even though the filesystem is full.

I can't find any patches which match your problem. I think I would create a small program using write and observe the errno value
as well. This will prove very valuable in narrowing down the actual problem.

Regards, Clay

[Roger Baptiste]

hi,

are all the systems running the same O/S version?

To narrow the problem, you can run a simple C script
containing fwrites to see
whether it works.

-raj

[harry d brown jr]

Check your kernel param's, and also:

Synchronous-Write Data Logging
Use these buttons to specify how small write requests are to be handled when a file is opened with the O_SYNC flag set:

Enabled ?? (default) Select this button to set the datainlog mount option when the mount_vxfs command is used to mount the file system. When synchronous-write logging is enabled, VxFS performs small synchronous-write requests by logging both the data and the new access-time change to the inode.

Disabled ?? Select this button to set the nodatainlog mount option when the mount_vxfs command is used to mount the file system. When synchronous-write logging is disabled, VxFS records the data in the file and updates the inode synchronously before returning to the user's program.

Which option you choose affects file-system performance (speed), but does not affect data integrity. If you expect large numbers of small write requests to the file system, enabling synchronous-write data logging can make file system write accesses somewhat faster.

See mount_vxfs(1M) for more information about these options to the mount command when used with VxFS file systems.

live free or die
harry

[Bill_14]

Hi,

Thanks for al the input. In answer to some of your questions:

D and R boxes are 32 bit, the A server is 64 bit

Additional information : After adding a call to statfs, the program was able to detect that the disk was full by examining f_bfree portion of the structure.

Also, while the test program is running on the A server, repeated calls to bdf do not show the "avail" bytes decreasing...

[A. Clay Stephenson]

Hi Bill:

It sounds as though you need to report this as a bug to HP.

[Frank Slootweg]

Bill(/Clay),

As the manual page mentions, fwrite(3S) is a *buffered* (in the applications memory) write (normally BUFSIZ (1024 byte) buffers, see setbuf(3S)).

As far as I know, disk space is *not* allocated until the buffer is full and fwrite tries to write the buffer with write(2). At *that* time the write(2) will fail and all *subsequent* fwrite-s will fail as well.

So depending on how much data is lost, this may be (ab)normal behaviour.

[A. Clay Stephenson]

Yes Frank, I had the same thought. That is why I asked that Bill do a program using write and look at errno. I fully expected it to return ENOSPC. I would then like to look at the difference in default buffer sizes on 32-bit and 64-bit 11x. I am more concerned at the difference in behavior in the two OS variants.

[Bill_14]

Hi,

I have added a display of errno to the test program. At a point when the mount was full
(from another terminal)
vxfs: mesg 001: vx_nospace - /dev/vg00/lvol8 file system full (2 block extent)
cp: bad copy to a.c: write: No space left on device

The test program was still running, as follows:
Tue Nov 6 06:45:48 MST 2001
status = :1:, iteration 1680, len 23 errno = 0
Tue Nov 6 06:45:48 MST 2001
status = :1:, iteration 1681, len 23 errno = 0
Tue Nov 6 06:45:48 MST 2001
status = :1:, iteration 1682, len 23 errno = 0
Tue Nov 6 06:45:48 MST 2001
status = :1:, iteration 1683, len 23 errno = 0


Any thoughts?

[Bill_14]

Additional information :

When the program did "notice" that there was a problem, here were the results:


vxfs: mesg 001: vx_nospace - /dev/vg00/lvol8 file system full (1 block extent)
status = :0:, iteration 325, len 23 errno = 0
Tue Nov 6 06:59:03 MST 2001
Exiting from ferror return 32
Tue Nov 6 06:59:03 MST 2001

Note that the fwrite returned 0 items written, but errno was still zero. It took invoking ferror() to determine that there was a problem , but the return code equated to:
32 EPIPE Broken pipe

Bill.

[A. Clay Stephenson]

Hi Bill:

It appears as though we are missing a piece of data. Perchance is your fwrite writing to a pipe?

[Bill_14]

Here is what I am using. I was under the impression that this would be a file stream:

main() {

FILE *outfile;
int status = 0;
int fstatus = 0;
unsigned char bf[24];
int cnt;

strcpy(bf,"xxxxxxxxxxxxxxxxxxxxxxx");

outfile = fopen("tmp.log","a");

setbuf(outfile,NULL);

cnt = 0;
for (;;) {
status = fwrite(&bf,24,1,outfile);
printf("status = :%d:, iteration %d, len %d errno = %d\n",status
,cnt,strlen(bf),errno);
fflush(stdout);
system("date");
fstatus = ferror(outfile);
if (fstatus) {
printf("Exiting from ferror return %d\n",fstatus);
system("date");
fflush(stdout);
break;
}
cnt++;
disk_check();
usleep(10000);
errno = 0;
}

}

disk_check() {

char *pth ;
char nam[80];
struct statfs *statbuff;
int status=0;
float tmp;

statbuff = (struct statfs *) malloc(sizeof(struct statfs));
strcpy(nam,"/home/billc");
pth = &nam[0];

status = statfs(pth,statbuff);

printf(" avail = %d\n",statbuff->f_bavail);
/*
if (statbuff->f_bfree < 1000){
printf("Disk space exit\n");
fflush(stdout);
exit(1);
}
*/

}

[Frank Slootweg]

You write very small records, only 23 (or 24) bytes per record, so you can fwrite many records to the 1KB buffer *in the application's memory*, before fwrite has to call write(2) to write the buffer to the filesystem. I would expect that after writing many (+/- 45) records *after* the disk is full, the write(2) would fail and errno would be set.

Note however that the internal operation of fwrite is not documented and hence not guaranteed, i.e. errno *might* be set, but nothing says that errno *must* be set. Personally that strikes me as somewhat odd, because for example fprintf(3S) *does* refer to errno and the underlying write(), but fwrite(3S) does not. Strange, but apparently standard (see "STANDARDS CONFORMANCE").

After reading both manual pages, I think that your problem might be solved if you use sprintf instead of fwrite (assuming your records are 'text' records).

Another minor point: You do not save errno before printing it with printf. I.e. if printf clears errno, your code will fail. See what happens if you do it correctly.

And then there are the vxfs mount options which Harry referred to. Those might influence thing too. See mount_vxfs(1M) and write(2) and the other referenced manual pages for details.

[A. Clay Stephenson · Accepted solution]

Hi Bill:

Since you are using setbuf(outfile,(char *) NULL), your output is unbuffered. The rule when using streams is that only ferror is the reliable indicator of errors. Since you are using unbuffered output anyway, I suggest that you change to using open(),read(),write(), and close(), and possibly lseek(). That way I know that errno will be set and you won't have to do any hokey and slow filesystem stuff. I still think if you can make a small test program that behaves differently on 32-bit and 64-bit, you should report that. I don't really care if the fwrite zigs or zags but I do care that if it zigs in 32-bit land that it also zigs in 64-bit land. One minor point: Start using the sizeof() operator rather than hard-coding number of bytes to read/write; it will make you code much safer and more portable.

Regards, Clay

[Bill_14]

Hi,

After careful examination of what was going on on the system, I believe that the original problem reported to me on this issue was one of perception. It looks like the code will actually behave correctly, but because the bdf display showed 0 for available, the person testing it interpreted that as 0 bytes available.

In reality, I was able to see the output file still gaining in size until all of the space had been consumed.

Thanks to all responders for your inputs!

Bill