From owner-freebsd-hackers Sun Nov 15 12:03:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA27340 for freebsd-hackers-outgoing; Sun, 15 Nov 1998 12:03:51 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA27333 for ; Sun, 15 Nov 1998 12:03:49 -0800 (PST) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.9.1a/8.9.1) with ESMTP id UAA00347; Sun, 15 Nov 1998 20:01:16 GMT Message-ID: <364F330B.640A3512@tdx.co.uk> Date: Sun, 15 Nov 1998 20:01:15 +0000 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert CC: Mike Smith , peter.jeremy@auss2.alcatel.com.au, hackers@FreeBSD.ORG Subject: Re: [Vinum] Stupid benchmark: newfsstone References: <199811151913.MAA27668@usr07.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert & Co. wrote: > It's not clear to me that spindle sync, with various drive > performance features enabled, actually refers to anything more > than cylinder selection; i.e., that you couldn't argue that > drive-level optimizations, e.g., write caching, are lower level > than spindle sync. In other words, at what level do you actually > engage in synchronization? We used to have a fairly 'old' (SCO? It might have been) system, running a number of 1Gb SCSI Drive's (DEC 3107's I think) - we had the option to use 'spindle sync' - but never actually used it... As far as I can remember the doc's said it would only give you an advantage if you were using the drives in a mirrored or duplexed array, i.e. the same read would be issued to all drives, or all drives would perform the same write - and would complete more or less in the same time (due to the spindles being in the same position at the time of the read/write being issued), hence you shouldn't get additional rotational delay latency (tagged queing/caching should be the same for each drive in this instance - as they're all doing the same thing at the same time)... I guess the thinking was so long as you issued the _same_ command/commands & sequences to all drives, i.e. "Read this sector, write that sector" across all drives - they would all complete at the same time... I guess RAID5, 'un-pure' block allocation / concatentation / mirroring (either caused by the O/S or the drive remapping sectors etc. (which incidentally the 3107's do have ;-) - has caused this option to be pretty un-usable in todays world... Though the number of defects remapped on drives is normally pretty minimal (not that that is any real defense for bringing spindle synch back again ;-) I also seem to have a vague memory of talking someone through _not_ linking the Spindle sync. on their DEC drives to the sp.sync on their Seagate drives ;-) Though it would have probably been interesting... -Kp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message