From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 aAP6IfI0H2SvWgAASxT56A (envelope-from ) for ; Sat, 25 Mar 2023 18:52:50 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id YBwDIfI0H2QooQAAG6o9tA (envelope-from ) for ; Sat, 25 Mar 2023 18:52:50 +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 36F62DD68 for ; Sat, 25 Mar 2023 18:52:50 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pg848-0006N4-0t; Sat, 25 Mar 2023 13:52:32 -0400 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 1pg847-0006Mq-2O for guix-devel@gnu.org; Sat, 25 Mar 2023 13:52:31 -0400 Received: from mail-lf1-x12a.google.com ([2a00:1450:4864:20::12a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pg845-0007rD-E7 for guix-devel@gnu.org; Sat, 25 Mar 2023 13:52:30 -0400 Received: by mail-lf1-x12a.google.com with SMTP id q16so6192929lfe.10 for ; Sat, 25 Mar 2023 10:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679766747; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=A4HJBEpj89b25UTvBuJu8KbQSz5dGgVL9nWRTzisKOU=; b=oBhoT7hhhCd/UL7so5hBjjUtDgT2fCZOgTIfxgvE9910uAd6lPrfCf0SjFBZ4vecXX tT6zpfeH99C2/QdVQwNKYpmTrqeC6VbKEhfpAUOkn+TbpA/1G34G7xGWQvZGe7wEnH/F N6n6pDLMZM52vxGKYjiW/3fTGCCWPGfPJMSRayfkRowXy/+ry8VIUbciZiOmfMKKRz+7 9oYI7z4NTowN91nEpEOUbz6QyPDfSDJqGO6GovCxNI/6Gm4db01Y10VCoViJFMx6ko+E vCfe8ewX6TMo2HtYcNsRizACRTREr+sSIVI9glLCV2GYcXeuUu6UJ5BptFkA20yW2ybg XL1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679766747; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=A4HJBEpj89b25UTvBuJu8KbQSz5dGgVL9nWRTzisKOU=; b=oVTEIYoA5wfldEXNzIqOeFtWyFsZ0z8xTU2ztvGqYhIzBqI80GhDEbpsE1QbJG6E88 8xE2Oq39AUKWmYrBAGOD62j7X1USyyeP3Zwnry7f18+YIDU5kzmqUdJqVxCQb2msUX9i AqVJnnrBODGb03Gs9W/a/HL/Ngo72c3X652BPghcFu3NHLZcAC+4QUbnZV3tjm1y21zr lat/Zdhvyp9cmeNAorfCcVI/zpbyahOTyby/qtmgkI1vNEfO4yrk7SOtZbGVghvLU1I4 uBRmsXXiLLOmqZ9ubElwVczBtKvuS4SxXSWrE/kNh6GmJdaCYGrZohfVA2lcg8GDZnii CN7w== X-Gm-Message-State: AAQBX9fDIY2+031UOkrWds65cBD06ZsaLBROgHdwhw5imspzDehGl5Lp pIgEJLO4vLoADM0Gcew1sGmDmsfqWr4= X-Google-Smtp-Source: AKy350ZUeItchbBXsjfjGSw6xcjZ35ZuicR0T3/MJLeoPS/y81hO55SwCJ9rjXbgaEfO8+vVSRrAvQ== X-Received: by 2002:adf:f1d0:0:b0:2cf:eb5d:70b5 with SMTP id z16-20020adff1d0000000b002cfeb5d70b5mr3606263wro.15.1679723273733; Fri, 24 Mar 2023 22:47:53 -0700 (PDT) Received: from lumine.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id p5-20020a5d4e05000000b002d75909c76esm12963113wrt.73.2023.03.24.22.47.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Mar 2023 22:47:53 -0700 (PDT) Message-ID: <84fd037856c3f8d8778556b1496e64624ceaf80d.camel@gmail.com> Subject: Re: Herding file-systems From: Liliana Marie Prikler To: Bruno Victal , guix-devel Cc: Felix Lechner , Maxim Cournoyer , bjc@kublai.com Date: Sat, 25 Mar 2023 06:47:52 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.0 MIME-Version: 1.0 Received-SPF: pass client-ip=2a00:1450:4864:20::12a; envelope-from=liliana.prikler@gmail.com; helo=mail-lf1-x12a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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: 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-Country: US X-Migadu-Flow: FLOW_IN ARC-Seal: i=1; s=key1; d=yhetil.org; t=1679766770; a=rsa-sha256; cv=none; b=A2AuuQaLWXw6Df6j2ZeUOPfqmeSgHHuVqGc8RlAcXpF7xVRowqvj/cFwjNutG8aVSzrD1a VBQVR9bfZL4oWwP37a2+eBhMNKrOo2rayX45tD+dVBFtAVk5dlUVbeKtrvez7QlAlTJZkm dcRsEgl1wWImfgiog4w6JsN0GvAkQziFf/gT5lHZIbmct0l4hDRyvdv/abtbMiYpO1H0rU gpo+kYLeJ6FVpDGNC5f1/BfQf5d50I5w3W7PXdLisKsaj/i9rJ8hKMK5rYCGr1YBqh1bsV BQRfyLNAw8jA96UB8Om0uAxaOmNjRUoyCMp0LcBy4ZRqbYPbro/GD9M4Je/9dg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=oBhoT7hh; dmarc=pass (policy=none) header.from=gmail.com; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1679766770; 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: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=A4HJBEpj89b25UTvBuJu8KbQSz5dGgVL9nWRTzisKOU=; b=q4A5OdQXARjEHfDlehuWfzEYsPgQmxbDbokeYaSeBS8VNdPg5eFjp5APi23y6LXAZSKGzm az93bCoG8QsADR6zljlr18sndL1MUYWbUVef/4x/zOn/GeAkd0gpLTqQWSmQ9orpVW4J/5 Q6Af5SKg250UxW9AEk3hWgHoKQr6uXGgzEAqaExp+k+xrpMOqUgNxKE8SIQzJRpj/DbfMM s+UeobCSd2GCScHJQQsj0Z1F6bz/fOj44HrC2BMiXrRezbBkxmAoFusL68oP2MgdFX5O8c EjKpcUJhq8UFWPQZqXHSjuSlXmYB8V+JByYc816eQd7JFSgSFfhvkCwdHgXTug== Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=oBhoT7hh; dmarc=pass (policy=none) header.from=gmail.com; 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" X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -4.97 X-Spam-Score: -4.97 X-Migadu-Queue-Id: 36F62DD68 X-TUID: fz4iWoqY7zwY Am Mittwoch, dem 08.03.2023 um 14:54 +0000 schrieb Bruno Victal: > Co-authored-by: Felix Lechner >=20 > Some observations and potential plans of action to improve file- > system handling and proper NFS support within Guix. >=20 >=20 > Relaxing dependency field of file-system record type > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 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. >=20 > A prominent example is NFS, which should depend on 'networking but > currently doesn't. Sounds fair so far. >=20 > Networked file-systems (such as NFS) > --------------------------------------------------------------------- >=20 > 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. >=20 > 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. And here I see potential for possible over-engineering. Since all our file-systems are already handled by shepherd, I see no need in "herding" them, as the title implies. What is needed, OTOH, is a way to inject shepherd dependencies, e.g. on networking, but possibly also on other file systems (*cough* loop devices *cough*). > Name collision for mounts on the same path > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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. Uhm, why should we allow this? > 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. >=20 > 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. In which cases should these mounts be created by the operating system rather than a cheeky user, though? > fstab serialization criteria > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 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. This appears a somewhat separate concern to the rest here and I'd suggest investigating it separately, as this escape hatch can easily be added without thinking about the broader picture of network file systems. Cheers