From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id gEb2OOyhCGRfTgEASxT56A (envelope-from ) for ; Wed, 08 Mar 2023 15:55:40 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id WMTwOOyhCGQpCgEA9RJhRA (envelope-from ) for ; Wed, 08 Mar 2023 15:55:40 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id BF4EE51E4 for ; Wed, 8 Mar 2023 15:55:40 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1678287340; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=XbcDo6VEtRoP2S4forDRWBTmNFPwWEsfYlbLEg2RX6o=; b=TA5TRWyF3YpGk0Pgn9jyl2ipA/DfkszVC21ngd54wVW/4TDrFFrjZpPbMh6hHsv1dOBdu+ VfvMJZzUY2Oz6ahIR/mB+kIYSindN3TgsYo6JQsTS1TfUUMaKpjaJ1T+dxQbNAY7gYIg8H ezndStw6TuxrJUuBQDfq8F+FAEqTrDFx2/TYDA0c55nIEgdOLeWq9peuCfPO0B7KWkW0hz IRlRhSanz2K+/YsvPF1jFu+CDGY7px9upm3SJO4A/cdViqk1NZ2bIFdvfS4hz8G/54XO4O o+67iZmULe5XD47/1KW+lApIolplVrwqBSVPDj5KqnU2GGBuUa4b/TUkl9YUug== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1678287340; a=rsa-sha256; cv=none; b=KPvNVNGJgpFDxTaSF2zNHVuN36sfm0pRTPZbrgxwn9+k2fSyBf+yqzcCajbNzI9p5qOvtB OFVmKa6ZdX9pAXKwmo2bEhR2E9hZFGJkF+wr+3dHx/AItiW0thpirYaO0enAXF5xTWPt7w Qu9wtm5zhHUt9Gs8X4n7P6Ci8aXx4R2EDOJ86NWbwieAtfqS0twklMclcR5Byi6405SkDR 9wtscNCCUHKBe/jr4ex7gBoWOBub4pbzCTwI3hkh4AhrKSzRFmYgaJHrohFD47f8ooljO5 MnemOfYo6OoZawd1vKXv0vKc0CO9tdk/5RL23/GEhq1L8hlIIMVrTzx1bMhCBQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pZvC2-0005P9-74; Wed, 08 Mar 2023 09:55:02 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pZvC0-0005Or-C1 for guix-devel@gnu.org; Wed, 08 Mar 2023 09:55:00 -0500 Received: from smtpmciv3.myservices.hosting ([185.26.107.239]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pZvBy-00072U-BJ for guix-devel@gnu.org; Wed, 08 Mar 2023 09:55:00 -0500 Received: from mail1.netim.hosting (unknown [185.26.106.173]) by smtpmciv3.myservices.hosting (Postfix) with ESMTP id 622E9202E2; Wed, 8 Mar 2023 15:54:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail1.netim.hosting (Postfix) with ESMTP id 03554800A0; Wed, 8 Mar 2023 15:54:47 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail1.netim.hosting Received: from mail1.netim.hosting ([127.0.0.1]) by localhost (mail1-2.netim.hosting [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ioe6yaD7ijxp; Wed, 8 Mar 2023 15:54:44 +0100 (CET) Received: from [192.168.1.239] (unknown [10.192.1.83]) (Authenticated sender: lumen@makinata.eu) by mail1.netim.hosting (Postfix) with ESMTPSA id 8D2FC8009F; Wed, 8 Mar 2023 15:54:44 +0100 (CET) Message-ID: Date: Wed, 8 Mar 2023 14:54:40 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Content-Language: en-US To: guix-devel Cc: mirai , Felix Lechner , Maxim Cournoyer , bjc@kublai.com From: Bruno Victal Subject: Herding file-systems Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=185.26.107.239; envelope-from=mirai@makinata.eu; helo=smtpmciv3.myservices.hosting X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: X-Migadu-Scanner: scn0.migadu.com X-Migadu-Queue-Id: BF4EE51E4 X-Spam-Score: -2.10 X-Migadu-Spam-Score: -2.10 List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-TUID: kVZON+z8eEcV Co-authored-by: Felix Lechner Some observations and potential plans of action to improve file-system handling and proper NFS support within Guix. Relaxing dependency field of file-system record type =============================================================================== Guix currently envisions file systems to depend only on other file systems, but that restriction should perhaps be relaxed. In some cases, it may make sense to wait for any (shepherd) service, i.e. not just for ones that mount directories. These could be used to place a dependency on kerberos, etc. A prominent example is NFS, which should depend on 'networking but currently doesn't. Networked file-systems (such as NFS) ------------------------------------------------------------------------------- The prerequisite 'file-systems should probably be split into 'networked-file-systems and 'local-file-systems. That distinction is already commonplace in other distributions. The stage 'networked-file-systems would in many respects be similar to 'file-systems but also depend on 'networking. We would have to watch out for some inconsistencies, however. For networked file systems, for example, the setting (needed-for-boot #t) may be impossible---except perhaps for thin clients. In impossible cases, the configuration would error out. Ideas to implement NFS support ------------------------------------------------------------------------------- 1. Add a _netdev flag (à la systemd) Looks ugly? 2. Add a new prerequisite called 'networked-file-systems This serves as a generic catch point for network dependent filesystems. This is to be specified manually. (3.1 notes apply here) 3. Partition file-systems according to field 'type into 'file-systems and 'networked-file-systems. As a drawback, it would only be able to handle known file-systems, because that list would have to be hard-coded. Cons: Automatic partition precludes the scenario that there could be two shepherd services, one providing regular 'networked-file-systems and a custom one providing some 'my-custom-service symbol, where the latter is specifically intended for the file-system, since the file-system is forcefully grouped into 'networked-file-systems. 3.1 Alternatively forego partitioning between local and network filesystems and simply put a dependency on 'networking. The filesystem must be decoupled from the 'file-systems symbol to prevent circular dependencies. Comments: The decision criteria should be "which one is the most flexible/has the least implicit assumptions" here. Name collision for mounts on the same path =============================================================================== One additional concern is the naming of Shepherd services for file systems. We can no longer just create the name from mount point alone since those names would collide with filesystems that can mount over the same path. The concern is not as far fetched as it may initially appear. Examples would be FUSE filesystems and OverlayFS, but there are probably others. Some FUSE file systems are specifically mounted over an existing mount point in order to provide additional services like transparent access for compressed archives. Regarding OverlayFS, it's worth noting that it can mount multiple times over itself, though personally I don't know what the applications are for this kind of scenario, merely that it can be done. fstab serialization criteria =============================================================================== It's worth revisiting why/what are the issues (and whether they're still relevant) that made us exclude certain file-system declarations from being serialized to /etc/fstab. [1] Excluding serialization for certain types isn't a problem but there should be an escape hatch option to forcefully serialize them to /etc/fstab. Footnotes =============================================================================== [1]: https://issues.guix.gnu.org/60246 Cheers, Bruno