Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934742AbbEOOcI (ORCPT ); Fri, 15 May 2015 10:32:08 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:46967 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S934692AbbEOOcE (ORCPT ); Fri, 15 May 2015 10:32:04 -0400 Date: Fri, 15 May 2015 10:32:03 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: NeilBrown cc: Dave Chinner , Len Brown , , , , Len Brown Subject: Re: [PATCH 1/1] suspend: delete sys_sync() In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1391 Lines: 31 On Fri, 15 May 2015, Alan Stern wrote: > On Fri, 15 May 2015, NeilBrown wrote: > > > Some storage devices don't handle suspend as well as they should and lose > > requests resulting in corruption. They should obviously be fixed, but it is > > you who gets the problem reports and you are not in a position to fix them. > > So you want a general solution that hides those problems. > > sys_sync at suspend time is a sort-of solution because it flushes and waits > > so there is less in-flight IO immediately after a sys_sync and so less > > opportunity for a bad device to stuff up. > > But you seem to suggest that sys_sync isn't a complete solution and it > > doesn't guarantee that xfs is not doing some background metadata IO. > > > > Maybe a sensible thing to do would be to hook the "disk" devices into suspend > > and have them flush their queue and possibly send a CACHE_FLUSH command. > > That would provide more of a guarantee for you, and less of a cost for Len, > > would it not? > > The sd driver already does this. Sorry -- I meant that it does send a SYNCHRONIZE CACHE command. It doesn't flush the I/O queue. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/