Received: by 2002:a05:6358:53a8:b0:117:f937:c515 with SMTP id z40csp2626386rwe; Sun, 16 Apr 2023 01:47:36 -0700 (PDT) X-Google-Smtp-Source: AKy350ZqSf0H1MQwj8+MQ9B3Tm5K5StK7TLRhhwhmwldwDINLMaxUf/AGkEHcjLSaN2bk8YM4sgi X-Received: by 2002:a05:6a20:160e:b0:ef:511:d6fe with SMTP id l14-20020a056a20160e00b000ef0511d6femr4141822pzj.9.1681634856010; Sun, 16 Apr 2023 01:47:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681634855; cv=none; d=google.com; s=arc-20160816; b=cMOKfdUvRA9rHMx3oieYITlUc24TDe1HpsQk7s6iZ1gZS68MMNSME9+RZimF6M+zsV S4u8+72Yfv1ljHRt+1uo6cBoF2J5zqLAR+VyjpRQ0jRH+5Dofe2g2I/y7uDcQm+tSBYx 9kL5//yp6f+Pp8sBOTBLer/1KCM2CUxZKP0FuzKl7782R746ReYi5oYrv6rMmnNhoRwq jJV6illHihJDjqaYvh+J6qpaITe+CDZEwElpuXMYGsgzKKF+N4e5YhtuDM/b5AjjkrSI T/xzgNBKm1ztX64rhc4edZOK7iS4YoqCB4auB1W7PsYypUitFM3CD5nP9dPB6Ib2ELtg m1qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=xhR9Xuv7XBKFBY9afp9X2a/ZF6VAXaNCOKK5ItWapcA=; b=qOP6+QbIqiAODieizvJLWIahrRm/zvQqp6du92uUpRqmlO/ZuD5o0ntXNh8FmFCHgX qhlWnnnqSxD7BhJiEsp3g5VVJpwEP2hR3qS3cSRdnU18MQOFK0RI/Vi0bS05+PCbbPgk tdbTOPKw5YpbRE9av2mu/6H5yKS7Ptp9iMSplGM0z4RnljJ7EXMcIHwvTaarUmW2Nv1E 7jAaE001iL+KR/HqG4FCjfPukQwRAX8g1CrqYjLL3199jAloSo5jS/zKB4KM4kr02gdk MEpdxl9T6GsKwOHxkQz4VCYDExIi2H6d9C1WDVYmm23CgWyugQqYvF53kzAfDSTIoO0k NWBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=qg7mGTfq; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f8-20020aa79688000000b0062ae6345c6dsi8718430pfk.392.2023.04.16.01.47.21; Sun, 16 Apr 2023 01:47:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=qg7mGTfq; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229942AbjDPInf (ORCPT + 99 others); Sun, 16 Apr 2023 04:43:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54926 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229472AbjDPIne (ORCPT ); Sun, 16 Apr 2023 04:43:34 -0400 Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EB7171712; Sun, 16 Apr 2023 01:43:32 -0700 (PDT) Received: by mail-ua1-x931.google.com with SMTP id l13so152232uan.10; Sun, 16 Apr 2023 01:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681634612; x=1684226612; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xhR9Xuv7XBKFBY9afp9X2a/ZF6VAXaNCOKK5ItWapcA=; b=qg7mGTfqT3wrZx1Io9uHzOuDuCsVtAT9wGvXcYVa/++Wmo9l6He+CX4K0V+sSfRCAr +GD6EPEQDa6GN/c8PqwkcS8u8QvwpAc7dD9UUVxWBm+OIuo1W9hPjQGd2BN+wjxX3s7S xZV6USZncZY8n9Wm+LNPETEkzu3Q0yRQ/9v106lJ+Ygwpn7dawNxtCW+HQbFN8jHEW3a t9+myyYWknZgs+gArH1Ftit/deN2Nq13zrygYgarCd6hNnE7QHoGZQjkbhQRp4CEo9Is xhFFxIvX5ljD8dk8g2G3+FFyqKy3203aSTLSYZn8q4xUGddEGnplOEnEAxXOOtFsgNu/ PWuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681634612; x=1684226612; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xhR9Xuv7XBKFBY9afp9X2a/ZF6VAXaNCOKK5ItWapcA=; b=DxAhWGRZvs6PN551I2zZAINQZeEsn/ZGFTF4leoAg4OWU5Ow2pt9ejw6XqxQuVUkcS 0FOCTNAvG1OHS1NdYD9bO6u+gYc3XlS6GtCu9gqKsyfKyto7PrffTKJCjLnNPgFn2YBB aTH7DwmUE1sXrlXF4A18QwG3o2pWoxXvfGVgVHA5SpiRECJ4gZdJ+SBOMCWGAmNVmqyD ak/7kLQbDqRXRLg7USCyQw2qCiybhWuslqkrrrSU/fz7RJ0bTkKkJAVaNWWsbin7c2YT 2qWhsIiX+hCFTKM8Up98Vka31oSkBHQcKhAQzluuOHCtKoxo8purOi7oXLnyFweAQim6 pKpA== X-Gm-Message-State: AAQBX9cj8ZL7sM1IVb6Z8BFJMdj0t5LRIYnblCmnIHWf7y4WD4/99OMR 5klAyjUFGJJA0OdUAxEoNTvjXEC8YzJbSUpVIrwdhcv/X2o= X-Received: by 2002:a9f:3053:0:b0:771:f5ee:f4e with SMTP id i19-20020a9f3053000000b00771f5ee0f4emr6304992uab.1.1681634611942; Sun, 16 Apr 2023 01:43:31 -0700 (PDT) MIME-Version: 1.0 References: <9b689664-095c-f2cf-7ba5-86303df3722b@gmx.com> In-Reply-To: <9b689664-095c-f2cf-7ba5-86303df3722b@gmx.com> From: Amir Goldstein Date: Sun, 16 Apr 2023 11:43:21 +0300 Message-ID: Subject: Re: [Lsf-pc] [LSF TOPIC] online repair of filesystems: what next? To: Qu Wenruo Cc: "Darrick J. Wong" , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, xfs , linux-ext4 , linux-btrfs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Sun, Apr 16, 2023 at 11:11=E2=80=AFAM Qu Wenruo = wrote: > > > > On 2023/3/1 04:49, Darrick J. Wong wrote: > > Hello fsdevel people, > > > > Five years ago[0], we started a conversation about cross-filesystem > > userspace tooling for online fsck. I think enough time has passed for > > us to have another one, since a few things have happened since then: > > > > 1. ext4 has gained the ability to send corruption reports to a userspac= e > > monitoring program via fsnotify. Thanks, Collabora! > > Not familiar with the new fsnotify thing, any article to start? https://docs.kernel.org/admin-guide/filesystem-monitoring.html#file-system-= error-reporting fs needs to opt-in with fsnotify_sb_error() calls and currently, only ext4 does that. > > I really believe we should have a generic interface to report errors, > currently btrfs reports extra details just through dmesg (like the > logical/physical of the corruption, reason, involved inodes etc), which > is far from ideal. > > > > > 2. XFS now tracks successful scrubs and corruptions seen during runtime > > and during scrubs. Userspace can query this information. > > > > 3. Directory parent pointers, which enable online repair of the > > directory tree, is nearing completion. > > > > 4. Dave and I are working on merging online repair of space metadata fo= r > > XFS. Online repair of directory trees is feature complete, but we > > still have one or two unresolved questions in the parent pointer > > code. > > > > 5. I've gotten a bit better[1] at writing systemd service descriptions > > for scheduling and performing background online fsck. > > > > Now that fsnotify_sb_error exists as a result of (1), I think we > > should figure out how to plumb calls into the readahead and writeback > > code so that IO failures can be reported to the fsnotify monitor. I > > suspect there may be a few difficulties here since fsnotify (iirc) > > allocates memory and takes locks. > > > > As a result of (2), XFS now retains quite a bit of incore state about > > its own health. The structure that fsnotify gives to userspace is very > > generic (superblock, inode, errno, errno count). How might XFS export > > a greater amount of information via this interface? We can provide > > details at finer granularity -- for example, a specific data structure > > under an allocation group or an inode, or specific quota records. > > The same for btrfs. > > Some btrfs specific info like subvolume id is also needed to locate the > corrupted inode (ino is not unique among the full fs, but only inside > one subvolume). > The fanotify error event (which btrfs does not currently generate) contains an "FID record", FID is fsid+file_handle. For btrfs, file_handle would be FILEID_BTRFS_WITHOUT_PARENT so include the subvol root ino. > And something like file paths for the corrupted inode is also very > helpful for end users to locate (and normally delete) the offending inode= . > This interface was merged without the ability to report an fs-specific info blob, but it was designed in a way that would allow adding that blob. Thanks, Amir.