Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934549AbbEOOUU (ORCPT ); Fri, 15 May 2015 10:20:20 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:46951 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S934083AbbEOOUR (ORCPT ); Fri, 15 May 2015 10:20:17 -0400 Date: Fri, 15 May 2015 10:20:16 -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: <20150515110417.1e3bbe12@notabene.brown> 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: 1216 Lines: 26 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. 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/