Date: Mon, 29 Aug 2005 20:59:33 +0200 From: Matthias Buelow <mkb@incubus.de> To: Don Lewis <truckman@freebsd.org> Cc: freebsd-stable@freebsd.org, dinom@balstonresearch.com, markir@paradise.net.nz Subject: Re: Sysinstall automatic filesystem size generation. Message-ID: <20050829185933.GB1462@drjekyll.mkbuelow.net> In-Reply-To: <200508291836.j7TIaVEk013147@gw.catspoiler.org> References: <20050829120415.GA1462@drjekyll.mkbuelow.net> <200508291836.j7TIaVEk013147@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Don Lewis wrote: >> I'd like to stress the "probably". I've already seen unrepairable >> filesystem corruption with softupdates enabled in the past with >> "good" scsi disks at power loss. > >Did you remember to disable write caching by setting the WCE mode page >bit to zero? At least with SCSI, it doesn't seem to affect performance >under most workloads. No.. I thought that with SCSI it is "ok" to leave the cache enabled because SCSI supports some sort of request queueing which doesn't break the order established by softupdates? >I've seen this when doing compile, run, panic experiments. The >executable that I just compiled would end up with a size of zero after >the reboot because it was still cached in RAM and executing from RAM >when the machine paniced. The executable was scheduled to be written to >disk about 30 seconds after it was compiled and linked, but the machine >paniced before the 30 seconds was up. Yes, that would account for the 0-size files but not for ones that got deleted by background fsck, with it logging "UNREF FILE" messages (and that were files that have definitely NOT had directory entries removed since amongst those were dot-files in my homedir, which I had to restore from backup then, and some others where I have not yet found out which they were..) >Softupdates only tries to guarantee that the on-disk file system is in a >consistent state at all times, with the possible exception that not all >space may be accounted for. It doesn't try very hard, though, nor is it very successful. mkb.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050829185933.GB1462>