ksh: get an error, when filesystem is full (vx_nospace)

[support_billa]

hello,

i allocated today too much space in a filesystem and wondering, why i didn't get an error. is it possible to get an error with "echo xxxx > /<fs>/file"

example:

Filesystem is full:

Filesystem                          kbytes       used      avail %used Mounted
/dev/vgtest/config                   16384      16384          0  100% /test_fs

no error , when i reached 100 % :

echo "test" > test; RET=$? ; echo "RET: $RET"  
vxfs: msgcnt 28 mesg 001: V-2-1: vx_nospace - /dev/vgtest/config file system full (1 block extent)RET: 0

no error , when i reached 100 % :

touch test;  RET=$? ; echo "RET: $RET"    
RET: 0

example, i get an error:

cp /etc/hosts . ; RET=$? ; echo "RET: $RET"

vxfs: msgcnt 26 mesg 001: V-2-1: vx_nospace - /dev/vgtest/config file system full (8 block extent)cp: bad copy to ./hosts: write: No space left on device
RET: 1

[Duncan Edmonstone]

Can't completely explain this, but I presume it is something to do with "echo" being a shell built-in - if you use the actual command /usr/bin/echo you do get an error as in I tried:

# /usr/bin/echo fred >> fred

msgcnt 22 vxfs: mesg 001: vx_nospace - /dev/vg00/lvol6 file system full (1 block extent)
/usr/bin/echo: No space left on device
# echo $?
2

[Dennis Handly]

>why I didn't get an error. is it possible to get an error with "echo xxxx > /<fs>/file"

You may have to use tusc to see where the error is.

Also it may depend on how much you write.  Have you looked at "file" above to see if the string was written?

Also if the file wasn't empty, there would have been room before.

[Duncan Edmonstone]

>>Also it may depend on how much you write.  Have you looked at "file" above to see if the string was written?

>>Also if the file wasn't empty, there would have been room before.

In the OPs case, both of those might have been true - however he is correctly pointing out that the echo shell built-in in the ksh shell does not return an error code when writing to a full filesystem - the same behaviour is seen whether appending to an existing file or a new one. Whether this is "by design" or not, I don't know

# echo fred >> fred

msgcnt 22 vxfs: mesg 001: vx_nospace - /dev/vg00/lvol6 file system full (1 block extent)

# echo $?
0

[Dennis Handly]

>he is correctly pointing out that the echo shell built-in in the ksh shell does not return an error code when writing to a full filesystem

It's kind of hard to tell without tusc or looking at the output file.  I.e. those console messages may be from some other user.  :-)

>Whether this is "by design" or not

Being sloppy is usually not "by design".  :-)

If you perform a gedanken experiment, is is easy to come up with a reason you can't detect that error.  In fact it is near impossible.  (Assuming you are using fwrite(3) instead of write(2).)

If you use fwrite(3) and you don't fill up the buffer, you won't get an error.  The first thing you learn about buffered I/O is that you must check for I/O errors on the fclose(3), where the write(2) is done.

So that seems simple but since the user never opened stdout, there is no place to check since it is closed in exit(2).  So the error is just thrown away.

So if you want to be pedantic, when writing to stdout/stderr, you must call fflush(3) and check before exit.  An that's probably what's missing.

[Duncan Edmonstone]

>> It's kind of hard to tell without tusc or looking at the output file.  I.e. those console messages may be from some other user.  :-)

I'm pretty confident the console messages were from my command, as I ran the test on my own workstation with only me logged in - however that was an old PA/11.11 box, so I'll repeat on an IA/11.31 box and see if I can post the tusc outputs

[support_billa]

>> >he is correctly pointing out that the echo shell built-in in the ksh shell does not return an error code when writing to a full filesystem

this is one point , what i mean .

i have a program , which generates an output . so i put the programmin a ksh script like

./program > outputfile

then the filesystem reach up the limit.

the ksh script didn't interrupt ... because no error occurrs.

but it is import that "./program > outputfile" works well, because the output is important .

so i think, i have no influence , when the filesystem gets full ?

regards

[Duncan Edmonstone]

so here's the output of a tusc trace attached to a shell - starting just before I hit return on the echo command into the full filesystem and finishing when I got back to the ksh shell prompt

( Attached to process 5385 ("ksh") [32-bit] )
[ksh         ][5385] read(0, 0x7fffe970, 80) ............. [sleeping]
[ksh         ][5385] read(0, "\r", 80) ................... = 1
[ksh         ][5385] ioctl(2, TCSETATTR, 0x400139f0) ..... = 0
[ksh         ][5385] write(2, "\n", 1) ................... = 1
[ksh         ][5385] lseek(63487, 14156, SEEK_SET) ....... = 14156
[ksh         ][5385] sigprocmask(SIG_BLOCK, 0x7ffff180, 0x7ffff1a0) = 0
[ksh         ][5385] read(63487, "/ u s r / l o c a l / b i n / t ".., 1024) = 106
[ksh         ][5385] sigprocmask(SIG_SETMASK, 0x7ffff1a0, NULL) = 0
[ksh         ][5385] sigprocmask(SIG_BLOCK, 0x7ffff180, 0x7ffff1a0) = 0
[ksh         ][5385] read(63487, 0x400d537c, 1024) ....... = 0
[ksh         ][5385] sigprocmask(SIG_SETMASK, 0x7ffff1a0, NULL) = 0
[ksh         ][5385] lseek(63487, 0, SEEK_END) ........... = 14262
[ksh         ][5385] write(63487, "e c h o   h e l l o   > >   m y ".., 22) = 22
[ksh         ][5385] fcntl(1, F_DUPFD, 10) ............... = 10
[ksh         ][5385] fcntl(10, F_GETFD, 0) ............... = 0
[ksh         ][5385] fcntl(10, F_SETFD, 1) ............... = 0
[ksh         ][5385] open("myfile", O_WRONLY|O_APPEND|O_CREAT|0x800, 0666) = 3
[ksh         ][5385] fcntl(1, F_GETFD, 0) ................ = 0
[ksh         ][5385] close(1) ............................ = 0
[ksh         ][5385] fcntl(3, F_DUPFD, 1) ................ = 1
[ksh         ][5385] close(3) ............................ = 0
[ksh         ][5385] fcntl(1, F_GETFL, 0) ................ = 2057
[ksh         ][5385] fcntl(1, F_GETFD, 0) ................ = 0
[ksh         ][5385] write(1, 0x40015840, 6) ............. ERR#28 ENOSPC
[ksh         ][5385] close(1) ............................ = 0
[ksh         ][5385] fcntl(10, F_DUPFD, 1) ............... = 1
[ksh         ][5385] close(10) ........................... = 0
[ksh         ][5385] fcntl(1, F_SETFD, 0) ................ = 0
[ksh         ][5385] sigvector(SIGCLD, 0x7ffff170, 0x7ffff180) = 0
[ksh         ][5385] waitpid(-1, 0x7ffff190, WNOHANG|WUNTRACED) ERR#10 ECHILD
[ksh         ][5385] sigvector(SIGCLD, 0x7ffff170, 0x7ffff180) = 0
[ksh         ][5385] time(0x7ffff1c0) .................... = 1359563133
[ksh         ][5385] lseek(63487, 14284, SEEK_SET) ....... = 14284
[ksh         ][5385] sigprocmask(SIG_BLOCK, 0x7ffff180, 0x7ffff1a0) = 0
[ksh         ][5385] read(63487, 0x400d537c, 1024) ....... = 0
[ksh         ][5385] sigprocmask(SIG_SETMASK, 0x7ffff1a0, NULL) = 0
[ksh         ][5385] ioctl(0, TIOCGWINSZ, 0x7ffff1b0) .... = 0
[ksh         ][5385] write(2, "#   ", 2) ................. = 2
[ksh         ][5385] ioctl(2, TCSETATTRD, 0x40013a20) .... = 0
[ksh         ][5385] ioctl(0, FIONREAD, 0x400138b8) ...... = 0
[ksh         ][5385] read(0, 0x40015420, 256) ............ [sleeping]

 So there does seem to be a write there rather than an fwrite which returns an ENOSPC

[Dennis Handly]

>it is import that "./program > outputfile" works well, because the output is important.

>I have no influence, when the filesystem gets full?

In my gedanken experiment I told you exactly how to fix echo, so it is your problem in your application, provided it is in C/C++.

You must check for errors after every fwrite, fprintf, printf, etc. to stdout/stderr.

AND you must call fflush(3) and check before exit.

Note: If you write lots of output, a check on one of those fwrite/printf calls should catch it.

>[ksh ][5385] write(1, 0x40015840, 6) ... ERR#28 ENOSPC

>So there does seem to be a write there rather than an fwrite which returns an ENOSPC

Sure, since fwrite(3) or printf(3) isn't a syscall.

You might be able to see it at the high level by using exec or {...; } to redirect stdout and have several echoes.

[Duncan Edmonstone]

>> Sure, since fwrite(3) or printf(3) isn't a syscall

D'oh!

Wakey Wakey Duncan! - oh well...

[support_billa]

hello,

last question zu my message 7# :

>> ./program > outputfile

>> but it is import that "./program > outputfile" works well, because the output is important .

>> so i think, i have no influence , when the filesystem gets full ?

i have no alternative in a ksh script to get an errror , when file system gets full ?

regards

[Dennis Handly]

>I have no alternative in a ksh script to get an error, when file system gets full?

Again, if ./program is a executable, you need to fix it, as I mentioned above.

If it is a ksh echo command, this is a "bug" in ksh that needs to be reported.

[Matti_Kurkela]

> no error , when i reached 100 % :

echo "test" > test; RET=$? ; echo "RET: $RET"  
vxfs: msgcnt 28 mesg 001: V-2-1: vx_nospace - /dev/vgtest/config file system full (1 block extent)RET: 0

If you've ran this test before reaching 100%, you're overwriting the contents of the existing file with new content. As long as the new contents are shorter than or equal to the previous contents, no new disk space will need to be allocated: if the file "test" previously contained a significantly larger amount of data, this operation might even *free* some disk blocks.

> no error , when i reached 100 % :

touch test;  RET=$? ; echo "RET: $RET"    
RET: 0

A zero-length file may only need a directory metadata slot, not an actual data block. A single block that contains directory metadata can easily contain several metadata slots, so even if all the blocks are allocated, you may be able to add zero-length files to directories whose existing metadata blocks don't yet have all their slots in use.

> example, i get an error:

cp /etc/hosts . ; RET=$? ; echo "RET: $RET"

If ./hosts does not already exist, this command creates a copy of a file with non-zero length, requiring at least 1 new data block to be allocated. Obviously this will fail if the disk is 100% full.

Also remember that disk space is allocated in blocks. If the size of a file is not an exact multiple of the filesystem block size, you can always write at least some new data to the file, even if the disk is 100% full. But as soon as the last block of the file is 100% in use, the filesystem needs to allocate another data block to the file to add more data, and if the disk is full, this will fail.

[Dennis Handly]

>If you've ran this test before reaching 100%, you're overwriting the contents of the existing file with new content.

I think I already pointed this out and they refuted it.  I.e. they got the error using tusc.

And I'm easily convinced that it is hard to check if stdout is full, if you only write a "few" bytes.