From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 8CFFA158041 for ; Thu, 11 Apr 2024 12:26:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 19BD6E2A10; Thu, 11 Apr 2024 12:26:18 +0000 (UTC) Received: from uriel.iewc.co.za (uriel.iewc.co.za [IPv6:2c0f:f720:0:3::9a49:2248]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7F6DFE29FB for ; Thu, 11 Apr 2024 12:26:15 +0000 (UTC) Received: from [154.73.32.4] (helo=tauri.local.uls.co.za) by uriel.iewc.co.za with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1rutVM-000000004yw-0Mev; Thu, 11 Apr 2024 14:26:12 +0200 Received: from [192.168.42.196] by tauri.local.uls.co.za with esmtp (Exim 4.97.1) (envelope-from ) id 1rutVK-000000006Rx-2hQd; Thu, 11 Apr 2024 14:26:10 +0200 Message-ID: <1453ed97-2d2f-4bc1-aa67-7f31491a8ec8@uls.co.za> Date: Thu, 11 Apr 2024 14:26:10 +0200 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [gentoo-dev] netmount and glusterfs (fuse) dependency management To: gentoo-dev@lists.gentoo.org, Joonas Niilola References: <6c3aabbf-a4ec-4d0a-97d4-a7b7e01b678e@gentoo.org> Content-Language: en-GB From: Jaco Kroon Autocrypt: addr=jaco@uls.co.za; keydata= xsBNBFXtplYBCADM6RTLCOSPiclevkn/gdf8h9l+kKA6N+WGIIFuUtoc9Gaf8QhXWW/fvUq2 a3eo4ULVFT1jJ56Vfm4MssGA97NZtlOe3cg8QJMZZhsoN5wetG9SrJvT9Rlltwo5nFmXY3ZY gXsdwkpDr9Y5TqBizx7DGxMd/mrOfXeql57FWFeOc2GuJBnHPZQMJsQ66l2obPn36hWEtHYN gcUSPH3OOusSEGZg/oX/8WSDQ/b8xz1JKTEgcnu/JR0FxzjY19zSHmbnyVU+/gF3oeJFcEUk HvZu776LRVdcZ0lb1bHQB2K9rTZBVeZLitgAefPVH2uERVSO8EZO1I5M7afV0Kd/Vyn9ABEB AAHNG0phY28gS3Jvb24gPGphY29AdWxzLmNvLnphPsLAdwQTAQgAIQUCVe2mVgIbAwULCQgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRAILcSxr/fungCPB/sHrfufpRbrVTtHUjpbY4bTQLQE bVrh4/yMiKprALRYy0nsMivl16Q/3rNWXJuQ0gR/faC3yNlDgtEoXx8noXOhva9GGHPGTaPT hhpcp/1E4C9Ghcaxw3MRapVnSKnSYL+zOOpkGwye2+fbqwCkCYCM7Vu6ws3+pMzJNFK/UOgW Tj8O5eBa3DiU4U26/jUHEIg74U+ypYPcj5qXG0xNXmmoDpZweW41Cfo6FMmgjQBTEGzo9e5R kjc7MH3+IyJvP4bzE5Paq0q0b5zZ8DUJFtT7pVb3FQTz1v3CutLlF1elFZzd9sZrg+mLA5PM o8PG9FLw9ZtTE314vgMWJ+TTYX0kzsBNBFXtplYBCADedX9HSSJozh4YIBT+PuLWCTJRLTLu jXU7HobdK1EljPAi1ahCUXJR+NHvpJLSq/N5rtL12ejJJ4EMMp2UUK0IHz4kx26FeAJuOQMe GEzoEkiiR15ufkApBCRssIj5B8OA/351Y9PFore5KJzQf1psrCnMSZoJ89KLfU7C5S+ooX9e re2aWgu5jqKgKDLa07/UVHyxDTtQKRZSFibFCHbMELYKDr3tUdUfCDqVjipCzHmLZ+xMisfn yX9aTVI3FUIs8UiqM5xlxqfuCnDrKBJjQs3uvmd6cyhPRmnsjase48RoO84Ckjbp/HVu0+1+ 6vgiPjbe4xk7Ehkw1mfSxb79ABEBAAHCwF8EGAEIAAkFAlXtplYCGwwACgkQCC3Esa/37p7u XwgAjpFzUj+GMmo8ZeYwHH6YfNZQV+hfesr7tqlZn5DhQXJgT2NF6qh5Vn8TcFPR4JZiVIkF o0je7c8FJe34Aqex/H9R8LxvhENX/YOtq5+PqZj59y9G9+0FFZ1CyguTDC845zuJnnR5A0lw FARZaL8T7e6UGphtiT0NdR7EXnJ/alvtsnsNudtvFnKtigYvtw2wthW6CLvwrFjsuiXPjVUX 825zQUnBHnrED6vG67UG4z5cQ4uY/LcSNsqBsoj6/wsT0pnqdibhCWmgFimOsSRgaF7qsVtg TWyQDTjH643+qYbJJdH91LASRLrenRCgpCXgzNWAMX6PJlqLrNX1Ye4CQw== Organization: Ultimate Linux Solutions (Pty) Ltd In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-report: Relay access (uriel.iewc.co.za). X-Archives-Salt: 8b066602-ab98-4c2e-b2f6-514cea8f7931 X-Archives-Hash: 544fb49cab8c280a75563f658859c675 Hi Joonas, On 2024/04/11 12:02, Joonas Niilola wrote: > Hey, > > On 11.4.2024 9.14, Jaco Kroon wrote: >> The latter can certainly be done and makes sense (only required if >> you're using the fuse mount, so if USE=fuse at least). >> >> The former doesn't make sense to do blindly in /etc/init.d/netmount >> (which belongs to sys-apps/openrc, not glusterfs). >> > well I was thinking about putting that into glusterfs's init file. Well, that's an obvious assumption now that I think about it, but incorrect for what I'm looking at. There's two init scripts for glusterfs, glusterd and glusterfsd. glusterfsd init script is being dragged along for historic purposes and comes from before I got involved, and I believe this was the way bricks were brought up prior to glusterfs version 3.0, and it does look like there is (u)mount stuff in there too.  This init script already has stuff for "need fuse" if it's mounting a glusterfs filesystem.  It looks interesting even now for *mounting* file systems, but in my opinion not for managing volumes. IMHO the more modern/better way is to bring up glusterd on nodes that *host* the volumes, ie, where bricks reside, and to then mount filesystems from /etc/fstab using netmount as part of mounting all network filesystem.  Otherwise you need to duplicate the init config for every mountpoint and specify a large number of arguments in those ... in my opinion it just gets messy quite quickly. glusterd then manages starting/stopping of brick, shd and other processes related to any volumes. netmount handles mounting of network (including glusterfs) filesystems. In many scenarios the storage nodes and those that consume them are independent.  In this scenario glusterd (along with bricks and shd's) will run on the storage nodes but not on the "compute" nodes, and there is no dependency between glusterd and netmount. glusterd does need to start before netmount if (and only if) there are glusterfs mounts in /etc/fstab that depends on the local glusterd for finding volume information.  This is hard(ish) to determine (reliably), but given "fstabinfo" in openrc-run I could amend /etc/init.d/glusterd's depend to do "before netmount" iff there are filesystems in /etc/fstab that's relevant.  We don't (currently) have such deployments, and we generally do have glusterfs mounts where we run bricks, even if only to be able to inspect what's going on in the "constructed" filesystem, so the explicit "before netmount" in glusterd doesn't bother me too much personally (even if it starts before netmount and it's not needed, who cares?  So lots of effort for little gain). glusterfs and fuse.glusterfs has already been added into /lib/rc/rc-functions.sh.  So technically I no longer need to flag my mounts with _netdev. Incidentally:  I *suspect* the noauto detection in netmount's depend will only work if noauto is the *first* option for any given nfs mountpoint. Anyway, I would thus like to suggest two "tweaks" to openrc here: 1.  net_fs_list needs to become more dynamic such that other packages (such as glusterfs) can add to the list dynamically. 2.  packages should be allowed to hook into netmount's depend() phase. If 2 isn't acceptable, I'll just send the desired changes for 2 directly into openrc as a PR, and that kinda makes point 1 pointless as well. Kind regards, Jaco