Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Mar 95 9:42:54 MST
From:      terry@cs.weber.edu (Terry Lambert)
To:        davidg@Root.COM
Cc:        peter@bonkers.taronga.com, hasty@star-gate.com, hackers@FreeBSD.org
Subject:   Re: Why IDE is bad
Message-ID:  <9503231642.AA18596@cs.weber.edu>
In-Reply-To: <199503230609.WAA00166@corbin.Root.COM> from "David Greenman" at Mar 22, 95 10:09:01 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> >>    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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503231642.AA18596>