From owner-freebsd-hackers Thu Mar 23 08:50:39 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA14476 for hackers-outgoing; Thu, 23 Mar 1995 08:50:39 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id IAA14467 for ; Thu, 23 Mar 1995 08:50:38 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA18596; Thu, 23 Mar 95 09:42:55 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503231642.AA18596@cs.weber.edu> Subject: Re: Why IDE is bad To: davidg@Root.COM Date: Thu, 23 Mar 95 9:42:54 MST Cc: peter@bonkers.taronga.com, hasty@star-gate.com, hackers@FreeBSD.org In-Reply-To: <199503230609.WAA00166@corbin.Root.COM> from "David Greenman" at Mar 22, 95 10:09:01 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > >> It should do what the manual page says it does, which is to force > >> all I/O to the filesystem to be done asynchronously. > > > >Um, all I/O to the file system is already done asynchronously. It's got > >internal sequencing of metadata but that shouldn't be visible to the > >process. > > It's the metadata I/O that we're talking about. ...and yes, the process > will definately see it if the operation involves lots of file creates. It is > inherently unsafe to do metadata I/O asynchronously, which is why the manual > page says: > > async All I/O to the file system should be done asynchronously. > This is a dangerous flag to set, and should not be used > unless you are prepared to recreate the file system > should your system crash. Oh, >*DUH*<. I've been thinking "bg". Which, Of Course, makes no sense on local disks. The use of "async" in this context doesn't "make no sense on local disks", it just "makes no sense period". The only exception to that is a tmpfs, which is clean on each boot anyway and might as well be remkfs'ed as anything else to get it clean. If you want to use async, you have to ensure that the writes occur in queue order rather than implementing elevator seeking; this almost universally implies log structuring the file system so that linear queue order writing is the optimal way to do writing. >From my examination of the LFS code, the main thing missing is lock state coherency, which can be fixed with ease by documenting lock state in and out in the comments for each routine, printing a call graph, and then manually checking lock states using only the headers. Hacking the code for single entry/single exit would help with this. The second thing missing is a per FS queue, which is the main thing causing it to be able to mount only a single FS before it gets confused. I don't think "async" should be an option, and if it must stay, at least say "DANGER! MOUNTING /dev/whazzit ASYNC!". Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.