From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BA35B3E5562 for ; Tue, 14 Apr 2026 12:07:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776168460; cv=none; b=c3kWo8VC/UXL80bjbUB2iSAkN6EBrMEy4nOcM63jO1i+62pvyhHLUJLfSoPkPaTVF97jw8eoNvAwCWdGK9UTRlfSkElPFksEhn/+rRCE4R2phiLKWNCtIO75U7rQgEDVPtcqxCQdgfAyjordYorIiNRiIZIN7NnJdEC4U7ILYj0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776168460; c=relaxed/simple; bh=C6PN2tv8TTYw6PZQNyyZ1Rg0SBPfgun9AXWA+SN5QCM=; h=From:To:Cc:Subject:In-Reply-To:References:Content-Type:Date: Message-Id; b=aGd7fVLzA+iJ5plCrG1EXwASYubj89RppQ7sLy27xoeJoJMhtj0YyQk1V3PIwYL9ngq5/rqaBQMkgKaqs5zSXB3TwC11AjXiFa6JGdEuyK9tADGAqJwoWIPHnU/VuNjnsTcSIWr83XqJhrmO2DFQdy+hP84c05ZwbQ3cJ7gxYVc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=hackers.camp; spf=pass smtp.mailfrom=gmail.com; arc=none smtp.client-ip=209.85.221.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=hackers.camp Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-43d7b879691so166724f8f.1 for ; Tue, 14 Apr 2026 05:07:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776168457; x=1776773257; h=message-id:date:references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GBVJRk9QryBisCG3/cC6tCqtgsY3R5164ZRYnE8QXr4=; b=cQexNYNNJJKd+4EPR1IW3BnwHjVHMaeqPzljehtn1ySN24Rn6h1fnPMCFfKR6svPof Yt9iZH1GLomqX58owfpXjiiQtTSSchHtAMVdabfT0R6k4sDRq6o0qZZ8EC8IMp+2hRfF /FVq/K29GxQJlZn0w77o+R+X/r4bF8pU48PJSjr0AnKWP9gKpkW11l0/5wAgrawgLInC pyQQcXWhs1AAPCJot5Yh29SZIZ+RHWO84QOkkGJTbP+Tzn29rUG5xvVQDRhA2XJKaTGR ypoHsDCyie1sWka6nu1lfXYlMFXpelZdBPDwAIZC11HsgfRG1pU2DfXG2ke/2n7AEwpp JC2Q== X-Forwarded-Encrypted: i=1; AFNElJ/64OLTBCYwko7O5P+bL9ajmN4OPmzs8nyLxzbS9e23MUPkJ5rhpF82YgR7c+pUSN47penM5Szp3f0uUxE=@vger.kernel.org X-Gm-Message-State: AOJu0YyA/IZclCOqlm7nILw17LNYZU1s48n/qcvMda5VvIuFcXPPwCBW peoTx/TMT67YKAzUEC95snhbAkxRf+A0efzXTNHlTqRzNTTRNfq/iqG0 X-Gm-Gg: AeBDieumWO2NQnb1BpqVA8JIVAUUm78mMYo4BkIaz/gm1StX0v1Ub6z/n/C84XmbN1K GX/84vCJZ89Op0rsCAK2cM8pjxLSzWDv+B/q+B5+pWD8vyUtaGesKrE8DaZMn9DrIykVgV4kjgW 5Z3092rOVPKRsfKA1vjS8inDeXdbswjgP3U2RVGwrnfIcdLRkorbr83r2c4BvnIc1fJrT7U0sw4 pFWzEJh4ep8DmMi4CR+DJCyHPeXz1afiN9glJXT4oXJnWDQzJTNRCV1g9eUnZkr5x5PQcFgy9U6 jwZ3vABD++XCqeyGQeL1rqol4DL5a3ALwTXUi3+xM1hGJf+8UrD2Pv61rXplxJUPF7QxPnzbW8l b/Z6rvD0aqocdlQklQ7qxngbJHqaa2+fCelUV4/+4jEIQ52dysCnIQSwo9O/tWvdjIlLzbDlYU/ ijrhd+Y963EXBccuZ9MNNshwbDa84XZoZRVcmegM/bMyv4Xps/IT4iD8S8NFDywVl0wDa4QyGV6 +amx+tqqdnaCDH8 X-Received: by 2002:a05:600c:3149:b0:487:575:5e3 with SMTP id 5b1f17b1804b1-488d68c7001mr110552565e9.5.1776168456905; Tue, 14 Apr 2026 05:07:36 -0700 (PDT) Received: from hackers.camp ([2a01:cb1c:784:2f00:708:2805:7128:7a75]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488ee03898bsm45341275e9.11.2026.04.14.05.07.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Apr 2026 05:07:36 -0700 (PDT) Received: (nullmailer pid 8795 invoked by uid 1000); Tue, 14 Apr 2026 13:30:36 -0000 From: Aurelien DESBRIERES To: Pedro Falcato Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, brauner@kernel.org Subject: Re: [RFC PATCH 0/10] ftrfs: Fault-Tolerant Radiation-Robust Filesystem In-Reply-To: References: <20260413142357.515792-1-aurelien@hackers.camp> Content-Type: text/plain; charset=UTF-8 Date: Tue, 14 Apr 2026 15:30:36 +0200 Message-Id: <1776173436.199615.8794.nullmailer@me> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: On Mon, Apr 13, 2026 at 03:04:11PM +0000, Pedro Falcato wrote: > Well, here's the obvious question: do you have a usecase for this? The target is embedded Linux systems in radiation-intensive environments where single-event upsets (SEU) cause silent bit flips in data at rest. Specifically: nanosatellites using MRAM or NOR flash as primary storage, with no block layer redundancy (no RAID, no mirroring, single device). The concrete use case is derived from the MOVE-II CubeSat mission at TU Munich (Fuchs, Langer, Trinitis — ARCS 2015). The paper documents measured SEU rates on commercial MRAM in LEO and shows that RS FEC at the filesystem level is the only mechanism that can recover corrupted data in place on a single-device system without external redundancy. The implementation is validated in a real arm64 HPC cluster (Slurm 25.11.4, Yocto Styhead 5.1, kernel 7.0) as a proof of concept for space-grade embedded Linux deployments: https://github.com/roastercode/yocto-hardened/tree/arm64-ftrfs > Well, as far as I can see, there's no write path, no read path (no > address_space_operations as far as I can see), no rename. Did you > test this? v1 was an RFC skeleton. These were addressed in subsequent versions: - v2: address_space_operations, write path, inode lifecycle fixes - v3: iomap IO path (replacing buffer_head, per Matthew Wilcox), rename, RS FEC decoder, Radiation Event Journal - v3: xfstests generic/001, 002, 010 equivalent validated on qemuarm64 kernel 7.0 > The layout itself is super unix-filesystem/ext2 reminiscent, so if > something like this is really needed, I would strongly recommend you > perhaps add this there. One feature (crc32c checksums over several > metadata structures) already exists on ext4. ext4 checksums detect corruption but do not correct it. fsverity detects tampering on read-only data but does not correct it. Neither provides in-place RS FEC correction on a single-device system. The certification constraint is also a hard requirement for the target environment: DO-178C (avionics), ECSS-E-ST-40C (space), and IEC 61508 (nuclear/industrial) require complete code auditability. ext4 at ~100k lines cannot realistically be certified under these frameworks. FTRFS targets under 5000 lines of auditable code. Aurelien DESBRIERES