From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: RE: [linux-iscsi-devel] [question] deferred sense Date: Thu, 06 Jan 2005 09:38:45 -0500 Message-ID: <1105022325.4319.21.camel@mulgrave> References: <60807403EABEB443939A5A7AA8A7458B9B9690@otce2k01.adaptec.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from stat16.steeleye.com ([209.192.50.48]:17586 "EHLO hancock.sc.steeleye.com") by vger.kernel.org with ESMTP id S262756AbVAFOiw (ORCPT ); Thu, 6 Jan 2005 09:38:52 -0500 In-Reply-To: <60807403EABEB443939A5A7AA8A7458B9B9690@otce2k01.adaptec.com> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: "Salyzyn, Mark" Cc: SCSI Mailing List On Thu, 2005-01-06 at 09:23 -0500, Salyzyn, Mark wrote: > However, you would see a similar problem being generated by a need for > quick and hot system failover and cache synchronization, bubbling all > the way up to the Linux disk cache; not just at the physical DASD level. > If the file-system is immune to a deferred failure from cached systems > (disk, RAID or linux cache), it will be hardened to deal with component > to complete system failover. Disc cache usually lies below the layer where failover occurs, so is definitely not a problem. If you're thinking of having a writeback cache in a raid card on a host, then you'll find all the documentation for clustering will explicitly warn you to switch it to write through (I know ours does). > Brute force, with performance penalty, is to periodically flush cache > (SCSI_SYNC command 0x35 being the weapon of choice), and when that > completes the Journal is cleansed. Added (performance) value, is to > survive a failover or deferred failure without the need to do this > synchronization. We already do cache sync on shutdown. The problem with periodic cache sync is the arrays which have huge caches (EMCs go up to gigabytes) which take ages to flush, so such a periodic sync can stall a system. James