From owner-freebsd-fs Fri Oct 2 02:52:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA25512 for freebsd-fs-outgoing; Fri, 2 Oct 1998 02:52:56 -0700 (PDT) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA25486; Fri, 2 Oct 1998 02:52:54 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id CAA10467; Fri, 2 Oct 1998 02:52:37 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id CAA04737; Fri, 2 Oct 1998 02:52:35 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id CAA15297; Fri, 2 Oct 1998 02:52:34 -0700 (PDT) Date: Fri, 2 Oct 1998 02:52:34 -0700 (PDT) From: Don Lewis Message-Id: <199810020952.CAA15297@salsa.gv.tsc.tdk.com> To: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: filesystem safety and SCSI disk write caching Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I was doing some torture testing of softupdates, CAM, and fsck by hitting the reset button on a running system and noticed that fsck would sometimes encounter inconsistencies in the filesystem that should not be happening, such as directory entries that pointed to unallocated inodes. I tracked the problem down to write caching being enabled on the machine's SCSI disk. After using camcontrol to disable write caching, this problem went away. It would be nice if folks in this situation would get a warning that their filesystems could get trashed because the disk has write caching enabled. I think the best situation would be to issue this warning at filesystem mount time (though folks who use async mounts shouldn't get an extra warning about write caching, their filesystems may get trashed anyway). This would require a communications channel between the filesystem and CAM. Another possibility would be to just issue a brief warning when the device is probed at boot time. Even a warning in the documentation would be helpful, at least for those who bothered to read it. BTW, with softupdates, and tagged command queuing enabled in CAM, there is not much of a performance hit from turning off write caching. I saw "make buildworld" increase from about 2 hours to 2 hours 5 minutes, and "make -j6 buildworld" increase from about 1 hour 30 minutes to 1 hour 35 minutes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message