From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5341FC43387 for ; Fri, 11 Jan 2019 13:28:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 207C42133F for ; Fri, 11 Jan 2019 13:28:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="JN4fk3t3" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731865AbfAKN2T (ORCPT ); Fri, 11 Jan 2019 08:28:19 -0500 Received: from bombadil.infradead.org ([198.137.202.133]:43188 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731063AbfAKN2S (ORCPT ); Fri, 11 Jan 2019 08:28:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1wqe8wVLTC88YPoo8/4/yk+HONqaLm0LOy52Cm8wKOA=; b=JN4fk3t3LbIrTngcL30zmJ4TA 51kV02b3gLfz+8d4ciDx+kUeJSp4P0L+ztXM3vW7ZAsdbQgSp9HrWOXMjlMIgSX+OklzlO3Khdy4b mLvL3LeV4aO+Rn9pT1060oyPeeJHRo+tA8AOp8Jqdx4u1OqCiIsWy5c2dBk6amPm3qsRBTlcI2pO8 rqBL2dUFOJW9Avj2iG+MGjyDb3w4WUJP1C++fzwEb3Cakix99hbaBg2x9tMei+JFb91b6/tPhcHQh k7/90+L+lVS4+6JfZDU4W46Dbgg0+HS5WISeG1S6KMV4G6YLkQCwFJcB5p/v8oJZOne2WKKeJyDfT r+Dihqzow==; Received: from willy by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1ghwrC-0003nk-7p; Fri, 11 Jan 2019 13:28:18 +0000 Date: Fri, 11 Jan 2019 05:28:18 -0800 From: Matthew Wilcox To: Steve French Cc: CIFS , linux-fsdevel , Pavel Shilovsky Subject: Re: scp bug due to progress indicator when copying from remote to local on Linux Message-ID: <20190111132817.GE6310@bombadil.infradead.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, Jan 11, 2019 at 12:11:00AM -0600, Steve French wrote: > In discussing an interesting problem with scp recently with Pavel, we > found a fairly obvious bug in scp when it is run with a progress > indicator (which is the default when the source file is remote). > > scp triggers "SIGALRM" probably from update_progress_meter() in > progressmeter.c when executed with "scp localhost:somelargefile /mnt" > ie with an ssh source path but a local path for the target, as long as > the flush of the large amount of cached data to disk (which seems to > be triggered by the ftruncate call in scp.c) takes more than a few > seconds (which can be common depending on disk or network speed). Are you saying the SIGALRM interrupts ftruncate() and causes the ftruncate to fail? > It is interesting that this can be avoided easily by running in quiet > mode ("-q") which disables the progress meter in scp, but it seems > very, very broken that scp of a large file can 'fail' when using a > progress meter (unless caching were disabled on the file system) due > to the slight delay in ftruncate due to triggering a flush of a large > amount of cached data to disk sequentially. > > Any thoughts of whether scp is actively maintained and best approach > to fix progressmeter.c so it doesn't break on Linux? > > -- > Thanks, > > Steve