System stalls at 4 gigs

[Andre Franklin]

Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 1048576 439232 605232 42% /
/dev/vg00/lvol1 1835008 325784 1497512 18% /stand
/dev/vg00/lvol8 8912896 3287464 5581984 37% /var
/dev/vg00/lvol7 10485760 2873840 7552480 28% /usr
/dev/vg00/lvol4 4194304 268984 3896936 6% /tmp
/dev/vg01/lvol3 262144 111225 141603 44% /salt
/dev/vg00/lvol6 20971520 7689032 13181296 37% /opt
/dev/vg01/lvol1 24576000 3379520 19871835 15% /indy
/dev/vg01/lvol2 262144 107666 144880 43% /hous
/dev/vg00/lvol5 2097152 262888 1820784 13% /home
/dev/vg01/lvol4 262144 59685 189923 24% /edmo
/dev/vg02/lvol1 52428800 26489996 24317661 52% /backup
/dev/vg01/lvol5 262144 1786 244093 1% /atla

[Andre Franklin]

fstyp -v /dev/vg02/lvol1
ksh: fstyp: not found

[Andre Franklin]

This file system was created on version: 6

[Steven Schweda]

> /dev/vg02/lvol1 52428800 26489996 24317661 52% /backup

Looks to me like about 24GB of free space.
Do you think that that's the problem?

> fstyp -v /dev/vg02/lvol1
> ksh: fstyp: not found

man fstyp

Around here, for example:

dyi # type fstyp
fstyp is /usr/sbin/fstyp

Of course, "HP-UX 64-bit" is not a very
complete description of your OS, compared
with, say, actual output from:

uname -a

so it's hard to be sure if you simply have
an insufficient PATH, or what else might be
wrong.

Also potentially interesting:

fsadm /backup

(And, as "man fsadm" should show, that's
"/usr/sbin/fsadm".)

> This file system was created on version: 6

Says who? As usual, showing actual commands
... Oh, wait. I already said that. (But,
apparently, it didn't take hold.)

Is it worth mentioning (again) that we still
have no real idea what you're trying to do,
or what actually happens when you try to do
it? One result of this lack of information
might be a lot of pointless guesswork which
may or may not luck into the solution of
whatever the actual problem might be.


> You really are a "glass half empty" sort of
> guy! [...]

Again, that doesn't tell us how much is in
the glass, or how much could be added. As a
wise man once said, "A pessimist says that
the glass is half empty. An optimist says
that the glass is half full. An engineer
says that the glass is twice as big as it
needed to be."

[Dennis Handly]

>MK: At exactly 4 GB, it reaches the maximum value that can be expressed with 32 bits.

Typically that occurs at 2 Gb, not 4, since file positions are signed.

[amipankaj]

It might be possible that the file system where file is getting copied was not created with largefiles option. In vxfs, if you want to put large files (bigger than 4gigs) you have to define this option.

[Laurent Menase]

or the other possibility is that the application used to extract the data is 32 bits and don't use open64() but open().


for instance like tar
if you want to tar to a file larger than 4G
tar cvf mytar mydir,
the size of mytar will be limited to 4G
you need to do
tar cf - mydir >mytar
because posixshell and ksh uses open64() syscall and not open().

if it is the case then the application should use either
open64()
or
use O_LARGEFILE flag when using open()
or
compile in 64bit mode


if the program can't be recompiled, then it is possible that using a fifo works

if for instance result goes to /tmp/logfile
mv /tmp/logfile /tmp/logfile.backup
mkfifo /tmp/logfile
cat /tmp/largelogfile&
start extraction to /tmp/logfile


Else check that the fs has well largefile enabled.

[Dennis Handly]

>you need to do: tar cf - mydir > mytar
>because posixshell and ksh uses open64()

This won't work if tar doesn't use open64 or O_LARGEFILE. You need to use a pipe and cat:
tar cf - mydir | cat > mytar

[Laurent Menase]

> >you need to do: tar cf - mydir > mytar
> >because posixshell and ksh uses open64()

> This won't work if tar doesn't use open64 or
> O_LARGEFILE. You need to use a pipe and cat:
> tar cf - mydir | cat > mytar

no cat is useless, because when you do cat >mytar or tar >mytar the open in both cases is not made by tar or cat BUT by shell which uses open64.
Tar or cat both inherit of the shell opened file as stdout mytar, which has the O_LARGEFILE flag set.

[Dennis Handly]

>Laurent: cat is useless

(Perhaps you meant unnecessary?)

>because when you do tar > mytar the open in both cases is not made by tar BUT by shell which uses open64.

I thought about that but I'm pretty sure I've gotten errors in the past?

I'm thinking that it's the write or lseek that will fail because they aren't the 64 bit version?
I just tested it and you're right, tar doesn't fail and doesn't use lseek(2).

But you can also solve it by using pax(1) instead of tar.