Re: kern/38717: sysinst shouldn't create LFS file systems

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/38717; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: Alan Barrett <apb%cequrux.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/38717: sysinst shouldn't create LFS file systems
Date: Wed, 11 Jun 2008 20:12:06 +0000

 On Mon, Jun 02, 2008 at 08:53:10AM +0100, Alan Barrett wrote:
  > > > Twice recently I have noticed files that ended
  > > > up with random binary content (of exactly the same size as the original
  > > > file) after a crash.
  > > 
  > > That's expected behavior in ffs-without-softdep.
  > 
  > Maybe.  I had the impression that, after a crash, files would usually be
  > missing, or moved to lost+found, or still containing old content (or a
  > mixture of old and new content).
 
 Well, what happens is that block pointers get updated synchronously
 without the data they point to having been written out; so if you
 crash you can get whatever crap was on the disk in that location
 previously.
 
 This has just come up on tech-kern, also.
 
  > >  > ffs with -o async [...]
  > > ... cannot reasonably be expected to work.
  > 
  > If what you mean is "there are known bugs in this area", OK; but if you
  > mean "crashing is not a bug" then I disagree. I expect the file system
  > to be left in a bad state if the machine crashes for some reason (due to
  > hardware failure or a kernel bug), but I do not expect the mere usage
  > of ffs-async to cause the machine to crash.
 
 Crashing is a bug, yes. I read what you wrote as meaning that the fs
 corruption after a crash was even worse, though; that is to be
 expected. (IME, crashes with ffs -o async are often unrecoverable.)
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost