2Gb. file limitation on 11.00 for non-root

[W.C. Epperson]

I've encountered the problem that non-root user IDs cannot create files or, apparently directories, that exceed approximately 2 GB, on an HP-UX 11.00 system.

Root UID's can create files in excess of 2 GB.

I've reproduced this problem on other HP-UX 11.00 systems. The problem does not occur on HP-UX 11.11 systems.

[A. Clay Stephenson]

You are probably hitting a ulimit value. Do a ulimit -H -a to display the hard limits and a ulimit -S -a to display the soft ulimits. This should be done for a regular user. This may be imposed by a setting in /etc/profile or in the user's .profile. You could also be limited by quotas if they are in play on a given filesystem.

[Victor BERRIDGE]

Are you sure your HPUX is not 32Bits?

All the best
Victor

[RAC_1]

How they are creating the files??

On which FS, does the that FS supports large files?? It is mounted with large files options enabled? Check it with following command.

fsadm -F vxfs /dev/vgxx/lvolxx
If it does not support it, you can modify it as follows.

fsadm -o largefiles /dev/vgxx/lvolxx
(you can do it online if you have OnlineJFS installed, else you will have to unmount the FS.)

Also make sure you add largefiles option to that FS in /etc/fstab file.

If the FS is mounted with largefiles option, then check at ulimit limits. -f option of ulimit controls the file size that can be created. (size is in 512 blocks.) man sh-posix for that.

Anil

[W.C. Epperson]

The system parameters are:

hostname = hp03
model = 9000/800/L2000-44
OS release level= B.11.00 (64-bit)
processor count = 2
CPU type = PA20
clock speed = 440 MHZ
memory = 5 GB

Using '/usr/sbin/fsadm' on the file system in question returns:

# fsadm /u01/sas
fsadm: /etc/default/fs is used for determining the file system type
nomultifsets
largefiles

Possibly relevant kernel parameters:

maxdsiz=1073741824
maxdsiz_64bit=2147483648
maxfiles=200
maxfiles_lim=1024
maxqueuetime=0
maxssiz=134217728
maxssiz_64bit=1073741824
maxtsiz=1073741824
maxtsiz_64bit=2147483648

As non-root user:

$ ulimit -H -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 1048576
stack(kbytes) 131072
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 200

"ulimit -S -a" is identical.

[A. Clay Stephenson]

Do a quota -v username for a user who is known to be having a problem. It would also be a very good thing to know the errno value, ${?} if the programmer followed UNIX conventions, when the problem occurs. This can't be a largefiles problem because it works for root.

One other thing that can cause this in hfs filesystem is min_free_percent (by default 10%). When the filesystem reaches this capacity, only root can add more blocks to file. It's possible that you are hitting this limit of big files and the process fails.

[W.C. Epperson]

The problem was encountered with SAS. SAS appears to "eat" the syserr and simply reports the highly descriptive "Out of Memory".

My test script hack uses 'cat' to create larges files, and that just gives an error of "1", and a text message of:

cat: standard output: Value too large to be stored in data type

I've confirmed the "root" versus "non-root" difference, by running the SAS job as "root" - and it ran to completion without any errors

[W.C. Epperson]

No quotas are set. "quota -v" returns column headings only.

[W.C. Epperson]

# bdf -i /u01/sas
Filesystem kbytes used avail %used iused ifree %iuse Mounted on
/dev/vg01/lvol1.3 25968640 13480980 12097798 53% 3963 1560957 0% /u01/sas

[Victor BERRIDGE]

SAS has a configuration file where you give limits, have a look if you should not change something there ~SASROOT/sasv8.cfg or something alike

[Sundar_7]

I faced similar problem in the past, and turned out that it is because of the shell I am using to invoke the shell script.

If it is a shell script which kicks of the jobs that create files > 2 GB then ensure you set the ulimit value in the beginning of the script.

Also I understand there is a slight difference in the way how unlimited is handled between KSH and posix shell.

[W.C. Epperson]

Continuing to bang around with our test script, we find that the non-root user can create a larger than 2Gb file with an initial "cat" statement, but the all attempts to append to it error as noted.

[Sundar_7]

may be a ulimit command right before the cat command will help you troubleshoot.

[W.C. Epperson]

If the ulimit is already unlimited, what would you set it to?

[Sundar_7]

You dont have to set the ulimit but just display the ulimit values before the cat command and confirm there is no "middleman" that changes the ulimit value.

[RAC_1]

You siad, appending to a file > 2gb is creating problem now. Right??

How about running the append command with tusc and get to the point which is causing the problem. Get tusc from porting center.

Anil

[W.C. Epperson]

We've tusc-ed all over the place. It doesn't help us with what ceiling we're hitting. I just thought it was curious that the initial write could be waaaaay over 2Gb, it's the next one that gets you.

[A. Clay Stephenson]

At this point, I would install the latest POSIX shell cumulative patch, PHCO_29768.

If this were me, I would write a little bit of C that does a write() so that I could see exactly what is failing and whar errno is being set to.

[A. Clay Stephenson]

At this point, I would install the latest POSIX shell cumulative patch, PHCO_29768.

If this were me, I would write a little bit of C that does a write() so that I could see exactly what is failing and what errno is being set to.