[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/38717: sysinst shouldn't create LFS file systems
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
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
Main Index |
Thread Index |