Date: Sat, 22 Apr 95 21:24:30 MDT From: terry@cs.weber.edu (Terry Lambert) To: gpalmer@freefall.cdrom.com (Gary Palmer) Cc: taob@gate.sinica.edu.tw, freebsd-current@FreeBSD.org Subject: Re: Fixing /dev entries (was Re: wcarchive down ) Message-ID: <9504230324.AA10199@cs.weber.edu> In-Reply-To: <24560.798562685@freefall.cdrom.com> from "Gary Palmer" at Apr 22, 95 07:58:05 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > If someone had physical access, would the solution be as simple as > >mounting the drive with the root filesystem on another FreeBSD > >machine, re-doing the /dev entries and then replacing the drive? I'm > >thinking ahead in case it ever happens to any of the machines here. > > If the /dev/*sd* entries were the only things affected, then yes. But when > we ran fsck on the drive a lot of the files normally considered non-optional > for a root filesystem bit the dust. It's either a complete re-install or > a upgrade to 2.x > > I'm not sure if anyone has fgured out what exactly happened yet, I'm > not at all sure and I was there watching this happen :-( There is still a nice hole for all you truck-drivers. The bdwrite for ffs_update() probably ought to be a bwrite if the inode being updated is a directory. I think it's possible that "current directories" for apps can ge corrupted by virtue of the inode being dirty for the access times. An explicit reading of POSIX allows you to treat a directory as if it were not a file, and only (synchronously!) update times on getdents (VOP_READDIR). I fixed this problem on UnixWare about a year ago, and was hard pressed to cause unreferenced files while flipping the power off during stress testing (before the fix, this would inevitably end up with crap in the lost+found directory). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504230324.AA10199>