From owner-freebsd-arch Thu Oct 14 4:13:11 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 832E414C27 for ; Thu, 14 Oct 1999 04:13:08 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA07380 for ; Thu, 14 Oct 1999 13:13:07 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA42008 for freebsd-arch@freebsd.org; Thu, 14 Oct 1999 13:13:07 +0200 (MET DST) Received: from critter.freebsd.dk (wandering-wizard.cybercity.dk [212.242.43.150]) by hub.freebsd.org (Postfix) with ESMTP id A5A0214C27 for ; Thu, 14 Oct 1999 04:12:55 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id MAA00449 for ; Thu, 14 Oct 1999 12:43:41 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-reply-to: Your message of "Thu, 14 Oct 1999 13:15:25 +1000." Date: Thu, 14 Oct 1999 12:43:40 +0200 Message-ID: <447.939897820@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [I know it was Julian who threw this ball in the air, but I take the liberty of doing the final round: I have been the primus motor on this issue from the beginning and it is part of the dev_t cleanup project.] SUMMARY: So far we have identified the following two classes of software which access disk-like devices through cdev and bdev: 1) Database software. 2) Filesystem maintenance tools 3) savecore(8) Database software prefer cdev semantics if at all possible, if running on anything but a cdev database software call fsync(2) a lot to make sure the writes have hit the media. Terry argues for retaining the bdev semantics rather than the cdev semantics, but I think we can dismiss that idea based on the above observation: it would penalize software which know better. Retaining the bdev would in essence be emulating the mistake Linux made, and which they are now unmaking. The filesystem maintenance applications mentioned so far which rely on bdev semantics, the EXT2FS tools, can be trivially converted to operate on cdev semantics. The majority of such tools already correctly operate on cdevs. Savecore(8) has already been converted to operate on cdevs. Using mmap(2) to provide a new type of buffered semantics for disk-like devices is insteresting, but its applicability will be limited by the virtual address space of a process: you can't map a 20GB database into a 32bit address space, so a lot of mmap(2) calls will be needed for serious sized data. The need for, and actual use of such a facility seemes uncertain. There is general disagreement about how much code we save, but nobody disputes that we will be able to remove some amount of complexity from the kernel. Most people seem to overlook the needlessly replicated code in a number of xxx(8) tools to DTRT with /dev/foo vs /dev/rfoo. Implementing an ioctl(2) to switch a disk-like device into bdev mode is relatively trivial, but there currently seems to be no point in doing so. There is a significant majority supporting the removal of bdev semantics. CONCLUSION: ----------- Unless we have significant new information to the contrary, I will commence the bdev removal after November 1st 1999. In order to try to trigger any such information, I will change the default value of the vfs.bdev_buffered sysctl to zero this weekend, this will make bdevs react like cdevs. An ioctl(2) based mode-switch will only be implemented if a very good reason for doing so materializes. Thanks for participating. Poul-Henning -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message