How to take down a system to the point of requiring a newfs with one line of C (userland)

[Peter Jeremy]

[CC list trimmed]

On Sun, Feb 17, 2008 at 10:24:08PM -0600, Jim Bryant wrote:
>How to repeat the problem:
>   Compile and run the following as instructed:
>
>#include <stdio.h>
>#include <stdlib.h>
>
>int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, 1024); 
>for(i = 0; i < 10000; i++) { sprintf(buf, "touch %s%05d\n", argv[1], i); 
>system((const char *)buf);} return(0);}
>
>/* pass a top-level mountpoint directory name of a mounted filesystem, with 
>a trailing slash to the above as argv[1], and run.
>
>This will create 10,000 zero-length files in the specified directory.
>
>umount that filesystem.
>
>perform a shitload of sync's to make sure everything outstanding is flushed 
>to disk on all filesystems.
>
>mount the target filesystem (preferably from a vty or serial console to 
>catch the messages when it panics, which it will as soon as the mount is 
>attempted).
>*/

FreeBSD pjfbsd6.alcatel.com.au 6.3-STABLE FreeBSD 6.3-STABLE #4: Wed Jan 23 08:21:27 EST 2008     root at pjfbsd6.alcatel.com.au:/var/obj/usr/src/sys/pjfbsd6  i386

I have been unable to reproduce the problem as described with or without
softupdates, even when I run the filesystem out of inodes.  I have also
tried filling '/'ä and rebooting to no avail.

That said, I did run into a bug where, for some time after deleting the
files from a soft-updates partition, 'df' would report that the inodes
were freed but attempting to create a new file would fail with ENOSPC.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080218/6ad7f475/attachment.pgp