Problems creating large files

[terrywashington]

One of our developers is having problems creating large files on our system running AIX 5.2. Here is the error message that is received.

File /qatest/cmf/large.db too large

This is a JFS and "large file enabled" is set to true. I recently changed the fsize value in /etc/security/limits to -1 as seen below thinking that this would allow all users to create large files. What else needs to be done to allow the creation of large files.

default:
fsize = -1
core = 2097151
cpu = -1
data = 262144
rss = 65536
stack = 65536
nofiles = 2000

 

[plamb]

More info what do you mean by "large files" did you set up file systems to do large file (>2gb)

 

[terrywashington]

Yes. I would like to be able to create files greater than 2GB on the filesystem in question. I thought that the smit setup was all that was needed. I then found out that the /etc/security/limits file had to modified as well. Here is the smit info for the filesystem.

[TOP] [Entry Fields]
File system name /qatest
NEW mount point [/qatest]
SIZE of file system
Unit Size 512bytes +
* Number of units [109051904] #
Mount GROUP []
Mount AUTOMATICALLY at system restart? yes +
PERMISSIONS read/write +
Mount OPTIONS [] +
Start Disk Accounting? no +
Fragment Size (bytes) 4096
Number of bytes per inode 4096
Compression algorithm no
Large File Enabled true
Allocation Group Size (MBytes) 64
[BOTTOM]

 

[bi]

Have you tried setting the data value in /etc/security/limits to -1, so it will be unlimited, too?

 

[raztaboule]

you should check in smitty users the settings for the user that should create the file.
i think that the changes you make in the defaulft stanza are not "propagated" but just available for creation of future users. also, if you change the settings for a user he/she will have to restart a session to take advantage of the changes.
bye.

 

[terrywashington]

I just set the data value to -1 and will have the user start a new session. Also we don't have any local users on the system. All are NIS accounts. I will post the results tommorow. Thanks for all the suggestions.

 

[letis]

hello terry,

A good point for limits, but in smitty you have to choose to create a "Large File enabled filesystem"; the smit's screen you show is related to regular JFS (there's no fragment size choice in the large file enable jfs screen).

regards,

 

[terrywashington]

I thought that I selected the "Add a Large File Enabled Journaled File System" option when I built the filesystem but I could be mistaken. The user has not tried to create the database since I made my latest changes to the system. If it gives the same error again I will backup the filesystem and rebuild it with the proper option. Thanks for the info.

 

[bi]

Check whether the filesystem is large-file enabled by issuing the lsfs -q /your_filesystem. If the results include bf: true, then the filesystem is large file enabled.

Have the user who is creating the large file issue a ulimit command to verify the user's settings.

 

[terrywashington]

It looks like the filesystem is setup for large files. I also su'd - USERNAME, issued the ulimit command and received "unlimited" as the output. I will post the results after the next attempt to create the large database. Thanks for the info.

# lsfs -q /qatest
Name Nodename Mount Pt VFS Size Options Auto Accounting
/dev/lv01 -- /qatest jfs 109051904 rw yes no
(lv size: 109051904, fs size: 109051904, frag size: 4096, nbpi: 4096, compress: no, bf: true, ag: 64)
#

# su - USERNAME
Login settings for AIX 4.2
% ulimit
unlimited
%

 

[bi]

Your last message says "Login settings for AIX 4.2". Is that a typo?

How does the user who is having problems log in as that user? Does he/she su - username or log in at the regular login prompt? If it's su - username, does that user know to use the "space hyphen space" between su and username? (I don't think not using the hyphen influences ulimit, but it might.)

 

[terrywashington]

The "Login settings for AIX 4.2" message was generated when I did su - to the user. This is probably old info within her .cshrc and is not a typo. The user normally logs in at the regular login prompt. She has been out of the office and has not tried to create the database again.