Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp817766ybv; Thu, 20 Feb 2020 07:50:42 -0800 (PST) X-Google-Smtp-Source: APXvYqyl2rjT7hx/lhvZFf8BuaFDf/Ay8BuqLJIiEdW5J4nSkfucWKJm8YiLii/KKj1Vp1f3fFHK X-Received: by 2002:a9d:638a:: with SMTP id w10mr11448959otk.130.1582213842164; Thu, 20 Feb 2020 07:50:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582213842; cv=none; d=google.com; s=arc-20160816; b=AKg+Foy7EZySslmHyBHRPmlfjjJ9ffpIvan/T53UVDddNtmqRCMmp9+xlsix7kvII1 P/N+graVZ9vVFLLcO3ZosogmoD52pXX/I4P9TGZten4V1twp/NjK0w5s8cNgrd4aDymy BO50R1QABiDkd+osII60abWQW+2oIbcpcb4a2joDwjV9vCx3KHBSxEdQikBJOcx28msB 22AU8Qn/wXqSvn39gGSY1wSDvDOQe8cGrNGuyeDINQL5rTfHpc8GRIrad+zfK3106WRS RXXwjJIUovDdRSbUnYdZLGl+ywi0S1nHcTmyqeSZAxbsaDnfA4IyVhVDyhH7uHRgvQHi qoCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=P4Xj9xldIKs24q++qYmmTkxA2oB1eeXVVF952IzRjLw=; b=p2ddKf0w2bpV9UnLr71EhYd0N52XrhsoBajPLTMVmqaOUUkgFD4V2gxqQ3MPZcvbp1 aV3/lV6gkl44KGQuhseDG5WVWOhvyOyMf96uJJhPe10wqUYUPdKLa57mIkspuYf6Hly1 PYPeDVIarE43Sy0aSJiNamxzSCrOr/URYyvsH6t9XYVT+JD9nRN4E8LNEicwcgLOo4Ri /9cvhcWmHR5Jk5+ScD244jWQHy9yLyLytYYWtZab8PRl3QVZWV6YnY7sZoYoqE8tqifW T8KN84GAIzQ4LhjLDprge4OrW1eWNqiYkDFWHCKgsjJ2uYAuwVpZ4rFFsi3wdCh8UnW8 2TAg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 64si1778884otx.50.2020.02.20.07.50.31; Thu, 20 Feb 2020 07:50:42 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728390AbgBTPua (ORCPT + 99 others); Thu, 20 Feb 2020 10:50:30 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:45407 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728387AbgBTPua (ORCPT ); Thu, 20 Feb 2020 10:50:30 -0500 Received: from callcc.thunk.org (guestnat-104-133-8-109.corp.google.com [104.133.8.109] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01KFoNHO009229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 Feb 2020 10:50:25 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id C43FA4211EF; Thu, 20 Feb 2020 10:50:22 -0500 (EST) Date: Thu, 20 Feb 2020 10:50:22 -0500 From: "Theodore Y. Ts'o" To: Jean-Louis Dupond Cc: linux-ext4@vger.kernel.org Subject: Re: Filesystem corruption after unreachable storage Message-ID: <20200220155022.GA532518@mit.edu> References: <20200124203725.GH147870@mit.edu> <3a7bc899-31d9-51f2-1ea9-b3bef2a98913@dupond.be> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3a7bc899-31d9-51f2-1ea9-b3bef2a98913@dupond.be> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu, Feb 20, 2020 at 10:08:44AM +0100, Jean-Louis Dupond wrote: > dumpe2fs -> see attachment Looking at the dumpe2fs output, it's interesting that it was "clean with errors", without any error information being logged in the superblock. What version of the kernel are you using? I'm guessing it's a fairly old one? > Fsck: > # e2fsck -fy /dev/mapper/vg01-root > e2fsck 1.44.5 (15-Dec-2018) And that's a old version of e2fsck as well. Is this some kind of stable/enterprise linux distro? > Pass 1: Checking inodes, blocks, and sizes > Inodes that were part of a corrupted orphan linked list found.? Fix? yes > > Inode 165708 was part of the orphaned inode list.? FIXED. OK, this and the rest looks like it's relating to a file truncation or deletion at the time of the disconnection. > > > On KVM for example there is a unlimited timeout (afaik) until the > > > storage is > > > back, and the VM just continues running after storage recovery. > > Well, you can adjust the SCSI timeout, if you want to give that a try.... > It has some other disadvantages? Or is it quite safe to increment the SCSI > timeout? It should be pretty safe. Can you reliably reproduce the problem by disconnecting the machine from the SAN? - Ted