Oracle dbwr open raw files with flag 0x800

[Mariusz Mróz]

Hi,

Does anyone knows why oracle background process i.e. ora_dbw0_% open data files on raw device with flag 0x800 ?

Example of tusc output:

10:32:44 [ora_dbw0_THD][11628] open("/dev/vgdata2/rlv_n2_thd_ewi_n3_thdmdev_01", O_RDONLY|0x800, 06440) = 318
10:32:44 [ora_dbw0_THD][11628] ioctl(318, DIOC_CAPACITY, 0x9fffffffffffb8a0) .............. = 0

10:32:44 [ora_dbw0_THD][11628] open("/dev/vgdata2/rlv_n2_thd_ewi_n3_thdmdev_01", O_RDWR|0x800|O_SYNC, 030) = 318
10:32:44 [ora_dbw0_THD][11628] fcntl(318, F_SETFD, 1) ..................................... = 0
10:32:44 [ora_dbw0_THD][11628] fcntl(318, F_GETFL, 0) ..................................... = 32770
10:32:44 [ora_dbw0_THD][11628] fcntl(318, F_SETLK, 0x9fffffffffffc0d0) .................... = 0


We may see that all system call open() use flag 0x800. I can't find a def. of 0x800 value in man of open() function:

NAME
open() - open file for reading or writing

SYNOPSIS
#include

int open(const char *path, int oflag, ... /* [mode_t mode] */ );

(..)
The oflag argument is a value that is the bitwise inclusive OR of
flags listed in "Read-Write Flags," "General Flags," and "Synchronized
I/O Flags" below.
(..)

Is it related to umask set for oracle user ? In this case 022.

Regards,
Mariusz Mroz

[Steven E. Protter]

Shalom,

I would suggest trying a different umask on the oracle user, restart the oracle server and see if you get the same results.

It is my thought that this is related to the way oracle was written, but is easy enough to prove.

SEP

[Dennis Handly · Accepted solution]

>open data files on raw device with flag 0x800?

Your tusc is "broken".

>I can't find a def. of 0x800 value in man of open

Why would it be there? It is more likely to be in , where it has:
O_LARGEFILE 04000

>Is it related to umask set for oracle user?

No, umask works with the next parm, if you were creating the file: 06440

[Mariusz Mróz]

You'e rigth:

1.
$cat /usr/include/sys/fcntl.h |grep -i large
#if defined(_LARGEFILE64_SOURCE) || defined(_KERNEL)
#endif /* _LARGEFILE64_SOURCE || _KERNEL */
* O_LARGEFILE is not defined for LP64 user programs.
* Such programs can always open or create large files
* O_LARGEFILE is never returned by fcntl F_GETFL to an LP64 program.
# define O_LARGEFILE 04000 /* large file open flag */
# define FLARGEFILE O_LARGEFILE
# if defined(_LARGEFILE64_SOURCE)
# endif /* _LARGEFILE64_SOURCE */
#if defined(_LARGEFILE64_SOURCE)
#endif /* _LARGEFILE64_SOURCE */
2.ad. "tusc "broken"
$tusc -V
tusc: version 7.9e, 2008/10/23, Copyright (c) 1996-2008 Chris Bertin (HP)

Now is a tusc v. 7.10. I'll deploy new version if problem with 0x800 flag occurs again in my platform I'll report a bug to hpux@connect.org.uk or to Chirs B.

3. ad. umask
Last filed of open() function arg are /* [mode_t mode] */ - this is a efective perms and are calculate with umask ? Is this correct ?

Regards,
Mariusz Mroz

[Dennis Handly]

>You're right:

No need to show the same file I just looked at. :-)

>Last field of open() function arg are /* [mode_t mode] */ - this is a effective perms and are calculate with umask?

Yes.