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 yGSFIJxDC2TANwAASxT56A (envelope-from ) for ; Fri, 10 Mar 2023 15:50:04 +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 oBygIJxDC2RLYQEA9RJhRA (envelope-from ) for ; Fri, 10 Mar 2023 15:50:04 +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 27E7D15455 for ; Fri, 10 Mar 2023 15:50:04 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=dtvSwBSK; 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=1678459804; 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=GSOsw7jShWsWUiJiJTlMTaXpXybjUbNLuowjUeStKf0=; b=OqLi5iLkRMl2w3MXMh39vAjnWMUGKErFocA/ZR3T9Opn75NydXis/fh7VdRmEO9Jwg4yBJ ZSeon/FBI38F+ke5iqxklVNnJqIvl8GDS8Dn341aY+3S42wJx6BL3fXkj4StGMI0haUX5q za9XQgeACrpJj2psWNnjitQdPaxPkGHBDtV76PXD1E/Yx2KXg2LSXcFiPzK4BrBv+4a/eE mXl1KNq3OEWjmkYBcpnhtBBh8fAkagpdAZyIPE33IKQ8znpWD9o6pqFOtpfvnNzlvrehH/ n4LOXJ2uNGdseaqCiwgRCrqRFyQMVazlnHrQmPJFjM9S+Lvg5/052EMcgWCCTw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=dtvSwBSK; 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-Seal: i=1; s=key1; d=yhetil.org; t=1678459804; a=rsa-sha256; cv=none; b=uNXmISWqixbAL/1S/QZc6t1rXJPUssE2kovIsWq4CekZWcesFXvdmqdnCyAP2uHA+wAThy jGjnmZRCsxF+g3nt81BC91N1Qep5nWCaf5s9IIp1xrJx2MnBtVt49b5c0lQwg9qu3BAU/B HWExLrqnPpi3VM9fjC9Ug1Ak0PBGNqDNgIm+rY8yrnHtawsYd9047VLjcOCMx9WSH5mk3z V1mjyWwCI1/qZgklcokjRgLcmojWDbsgVEECGhatZgyx2y7wIuN38vXooU6OmoWEcnbGAU Zpyc26gsnpuGEhNoVOn0iexo5MgCgh9bCGW9hZDQvbfxXVYC/UzZ8tikBx/Ueg== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pae3w-0004kx-Tp; Fri, 10 Mar 2023 09:49:40 -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 1pae3p-0004kd-AI for guix-devel@gnu.org; Fri, 10 Mar 2023 09:49:34 -0500 Received: from mail-qv1-xf33.google.com ([2607:f8b0:4864:20::f33]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pae3n-0003u5-Lj for guix-devel@gnu.org; Fri, 10 Mar 2023 09:49:33 -0500 Received: by mail-qv1-xf33.google.com with SMTP id nf5so3740312qvb.5 for ; Fri, 10 Mar 2023 06:49:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678459770; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=GSOsw7jShWsWUiJiJTlMTaXpXybjUbNLuowjUeStKf0=; b=dtvSwBSKf/NgmfbmdEZiT0CidpTTZIJUQZhWXjKDiYBxJUeBVMXYlNzAIVYTOp61gK hX59qTEaNhRYj29Q+cXvsYGAhB4XmoYzQ1RmZarVVGzJY7O0uwfVijrjjjUH5H1HGQWM D9FqLSVOoFN8WDpFNjIjs1AMURjgk/2sA9HGzlTdW9tvfALPM33a+ovfOg2Z8ydRsy8u CAZ1S9kI/AClsSxBjiuDUr0BMJLUnxRKJ535W2pMCRB9ETeiyvvYjBOaVAmJk8Em+KX0 csGsSfuN2jc/KioNgh94XhcR5PM3YgHOgDdCwC/eMMyRKADBON/VqgROly2F6dEkRX2C oj6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678459770; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=GSOsw7jShWsWUiJiJTlMTaXpXybjUbNLuowjUeStKf0=; b=q48cLlQVhqCZ6/C8Q5GRVHBlw7xZYmMAlg71JhlQhClzHJNoLkyseDW0SKWQJEO/xI nUK3zB45b4zvdEjEdyR78d8Ph7JBLuFoZ1i2MtiK68Gkr3uVrN0Du5Co8KENnFS26l6k 1pBqNDYHxGAsdhR+uQYy3NvCNax7JqUopgC00MrDpxrAJzdMerGoDo5Kn/CHWtBzpiPJ CFwA583cSm3/XNIqRPTKojJXfdAIWN6Y304tEaZ2eEXiJDwa7NPhxQkTk+tz/vwpew3A o0KAUE5SSUGtkJmC4aIOMv7vmd+MBNu4lnBwb/3gxmC8JwzMU/cn408BZWXSFIvZrSI9 inzg== X-Gm-Message-State: AO0yUKWIWX3SDGomwG724mEfz1yz0AvqUDcr5Kp9szDSa/h6bWGN7Gad OL7rg5VpR7cYu4SBRnEsVuk= X-Google-Smtp-Source: AK7set9Meqr4jEJpZSxE2dngvwsK+wJDopec5LPlhmgbCEmgiq0eczlsuSQtpAIdJ1FJy0jIGLMV5g== X-Received: by 2002:a05:6214:48e:b0:577:4ea5:2445 with SMTP id pt14-20020a056214048e00b005774ea52445mr48998516qvb.39.1678459770372; Fri, 10 Mar 2023 06:49:30 -0800 (PST) Received: from hurd ([2607:fad8:4:3::1000]) by smtp.gmail.com with ESMTPSA id 23-20020a370617000000b006ff8a122a1asm1433498qkg.78.2023.03.10.06.49.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Mar 2023 06:49:30 -0800 (PST) From: Maxim Cournoyer To: Bruno Victal Cc: guix-devel , Felix Lechner , bjc@kublai.com Subject: Re: Herding file-systems References: Date: Fri, 10 Mar 2023 09:49:28 -0500 In-Reply-To: (Bruno Victal's message of "Wed, 8 Mar 2023 14:54:40 +0000") Message-ID: <87pm9gr79j.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::f33; envelope-from=maxim.cournoyer@gmail.com; helo=mail-qv1-xf33.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: X-Migadu-Queue-Id: 27E7D15455 X-Spam-Score: -7.73 X-Migadu-Spam-Score: -7.73 X-Migadu-Scanner: scn0.migadu.com 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 X-TUID: Lz2eA/z1CWE7 Hi, Bruno Victal writes: > Co-authored-by: Felix Lechner > > > Some observations and potential plans of action to improve file-system ha= ndling > and proper NFS support within Guix. > > > 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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > 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 pla= ce a > dependency on kerberos, etc. > > A prominent example is NFS, which should depend on 'networking but > currently doesn't. Sounds good. > 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 (=C3=A0 la systemd) > Looks ugly? Very :-). Let's try to find a more elegant way. > 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-system= s and a custom > one providing some 'my-custom-service symbol, where the latter is spec= ifically > intended for the file-system, since the file-system is forcefully grou= ped into > 'networked-file-systems. I don't understand the cons, which perhaps suggests it'd be a bit of a stretched use case? > 3.1 Alternatively forego partitioning between local and network filesyste= ms > and simply put a dependency on 'networking. The filesystem must be > decoupled from the 'file-systems symbol to prevent circular dependenc= ies. > > Comments: > The decision criteria should be "which one is the most flexible/has the l= east > implicit assumptions" here. Another related idea; perhaps we could introduce a new record called 'distributed-file-system' and use this at the time of declaring the file system? That'd would automatically depend on networking in the underlying implementation; so I'd be able to specify it in my operating system like: (file-systems (cons* (file-system (device (uuid "43582534-54a1-415a-a8ac-ecc20867f7a3")) (mount-point "/boot") (type "btrfs") (options "compress-force=3Dzstd")) [...] (distributed-file-system (device "host:/srv/nfs/jami") (mount-point "/var/cache/jami") (create-mount-point? #t) (type "nfs") (options "soft,user")) It'd allow to decouple the and fully, providing flexibility to add new fields to the later in the future which would make little sense for the former. It's also more declarative than the "auto-determine networkness from type" (point 2 above) heuristic. Thanks for looking into this longstanding limitation! --=20 Maxim