From owner-freebsd-current  Mon Apr 17 19:41:14 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id TAA11157
          for current-outgoing; Mon, 17 Apr 1995 19:41:14 -0700
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
          by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id TAA11147
          for <freebsd-current@freebsd.org>; Mon, 17 Apr 1995 19:41:11 -0700
Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14457(1)>; Mon, 17 Apr 1995 19:40:35 PDT
Received: by crevenia.parc.xerox.com id <49864>; Mon, 17 Apr 1995 19:40:31 -0700
From: Bill Fenner <fenner@parc.xerox.com>
To: freebsd-current@FreeBSD.org
Subject: fsck trashes / if no /lost+found?
Message-Id: <95Apr17.194031pdt.49864@crevenia.parc.xerox.com>
Date: Mon, 17 Apr 1995 19:40:28 PDT
Sender: current-owner@FreeBSD.org
Precedence: bulk

I am running SNAP-950322.  I crashed hard, and on the way up, fsck tried to
reconnect a file when fsck'ing /usr.  Apparently, for some reason there was
no /usr/lost+found, and fsck printed an error something like "no room in /"
when it said it was trying to create it.  The fsck failed, and when I fsck'd
manually it said there was no /, and it ended up reconnecting all the
directories in /lost+found (after creating /lost+found).

I managed to reconnect most everything where it belongs, but having to
recreate /usr from /usr/lost+found is not something you want to do every
day.  I don't know enough about the ffs code myself to fix this, but if
someone feels like looking into fsck's behavior in this case it might be
a good idea.

(Of course, it's entirely possible that going down hard actually did trash
/usr's /, but I'm not convinced.)

  Bill