Date: Sun, 15 Nov 1998 20:01:15 +0000 From: Karl Pielorz <kpielorz@tdx.co.uk> To: Terry Lambert <tlambert@primenet.com> Cc: Mike Smith <mike@smith.net.au>, peter.jeremy@auss2.alcatel.com.au, hackers@FreeBSD.ORG Subject: Re: [Vinum] Stupid benchmark: newfsstone Message-ID: <364F330B.640A3512@tdx.co.uk> References: <199811151913.MAA27668@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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... <G> -Kp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?364F330B.640A3512>