Thanks to all who responded! I have since resolved the problem. I have
two questions below, but here's what I found based on everyone's
feedback.
First, I was originally running the nsrinfo command (nsrinfo client >
filename) in a bash shell on Solaris 2.8. Now, apparently, we have an
older version of this shell as I compared the version (bash -version)
with other bash shells on other machines and most are newer. To test
things, I tried running the following command:
mkfile 3000m foo
This works fine!
Next, I tried: dd if=/dev/zero bs=2048k count=1024 > testfile
This works fine. Next, I tried upping the count by 1 as:
dd if=/dev/zero bs=2048k count=1025 > testfile
dd: unexpected short write, wrote 2097151 bytes, expected 2097152
No matter how little or how much I increased the count, the error
message was always the same, and the output file created was always 2
GB. Okay, so next, I tried running the same 'dd' command in the Bourne
shell (`sh`). Eureka! It works fine in the Bourne shell. I also tested
concatenating various sized files, too, using 'cat'. This was something
I could not do successfully in the Bash shell, at least not with things
larger than 2 GB or so. All in all, I didn't test anything larger than
6-7 GB, but the Bourne Shell certainly had no problems with files in
that range. I have not since re-tried the nsrinfo command, but I'm sure
the Bourne shell will handle the output size just as it handled 'dd'.
Legato tells me that there should not be a limit with the nsrinfo
command.
I did not test any other shells, e.g. csh. I did try creating large
files on some other machines, and I found that on Linux, I had no
problems in either Bash or Bourne. However, the version of the Bash
shell on the Linux box was more recent. I did try another Sun with the
same older version of the Bash shell and it choked too on 'dd' in the
same manner but likewise allows 'mkfile' on larger than 2 GB files. Hmm
... I also tried the 'dd' command on another Sun running a newer version
of Bash and it works.
Question 1: Does the OS (32-bit versus 64-bit) have anything to do with
this?
'isainfo -v' shows 32-bit on this Solaris box and same on Linux box. The
other thing that seems a little odd is that the man page for 'largefile'
indicates that mkfile, dd and cat commands are all large file aware. I
would think since dd and cat are large file aware and not large file
safe then there would not have been a problem, but guess the shell can
inforce a limit?
Question 2: Why is it that when I run `ulimit -f`, in Bash shell, it
says unlimited? Seems like it is limited.
Thanks.
George
Darren Dunham wrote:
Hi George,
From the figures you've quoted, I'd imagine that you've hit the 2GB
limit on your output file.
The version of Networker you're running will be compiled 32 bit, so may
not be able to deal with larger files than this.
It's probably too late now, but for future you should be able to work
around this by creating a file-system pipe, setting up a process to
accept input from the pipe and send it to a "split" command, and then
running the nsrinfo command with the output going into the pipe. I've
seen this done to overcome a similar problem with Oracle Export files.
Was running 'nsrinfo client > outputfile' and it's stopped adding
Of course, in a way he's already done part of that. Due to the
redirection, nsrinfo isn't dealing with the file offsets directly, so
it's not the source of the 2G failing. Instead the redirection makes
the shell responsible for the offsets.
It is possible that simply using a different (largefile aware) shell
would be sufficient.
--
Darren Dunham ddunham < at > taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
--
Note: To sign off this list, send a "signoff networker" command via email
Note: To sign off this list, send a "signoff networker" command via email
