From owner-freebsd-current Mon Nov 27 00:08:40 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA12514 for current-outgoing; Mon, 27 Nov 1995 00:08:40 -0800 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA12504 for ; Mon, 27 Nov 1995 00:08:31 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id IAA03995; Mon, 27 Nov 1995 08:01:49 GMT From: Michael Smith Message-Id: <199511270801.IAA03995@genesis.atrad.adelaide.edu.au> Subject: Re: Prioritised disk requests To: sysseh@devetir.qld.gov.au (Stephen Hocking) Date: Mon, 27 Nov 1995 08:01:48 +0000 () Cc: current@FreeBSD.org In-Reply-To: <199511270628.GAA00550@netfl15a.devetir.qld.gov.au> from "Stephen Hocking" at Nov 27, 95 04:28:50 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1647 Sender: owner-current@FreeBSD.org Precedence: bulk Stephen Hocking stands accused of saying: > Has anyone thought of a mechanism (similar to stuff I've seen on > Masscomp machines) where one could indicate that a particular stream > of disk I/O had a higher priority than normal? Masscomp used to have > a B_URGENT flag for these blocks in the buffer cache (for > semi-realtime I/O when acquiring or transmitting data). CD burners > could do with this, or people trying to keep tapes streaming on > backups. As far as CD burners are concerned, going on the datasheets I have here, most would be pushing to beat 350K/sec, and have buffers in the >1M range. I doubt very much that anything other than a spammed-to-the-wall system is going to have the multi-second latency or sub-350K/sec net available SCSI bandwidth. (ref. phillips CDD522 glossy; 153.6/176.4/307.2/352.8 selectable xfer rates, standard buffer 2M, expandable to 8 or 32M.) The problem with old tapes is just the opposite - their buffers are too small 8) You'd have to tag both data going to the tape, and data for the backup process coming off the disk as urgent, and keep the disk requests short so that the tape could come back for more data. Not easy 8( (also, newer tape units have bigger buffers, so the problem is going away) > Stephen -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[