Re: [gentoo-dev] netmount and glusterfs (fuse) dependency management
On Mon, Apr 8, 2024 at 5:51 AM Jaco Kroon wrote: > > Hi All, > > I was hoping for some advise regarding how I could improve the glusterfs > package for users (and myself). At least those using openrc, but I > suspect similar may be applicable to systemd, but I have no idea how > systemd handles network mounts so perhaps someone could chip in here on > that front too. > > Specifically the mounting of glusterfs file systems currently has a few > problems (glusterd if server=localhost, network, dns(?) and fuse > availability). For now the focus is on the fuse aspect since that's the > biggest annoyance by far. > > Mounting happens via the netmount service. > > In order for glusterfs to mount successfully the fuse module needs to be > available when mount.glusterfs is invoked. This can be achieved in one > of two ways: > > 1. Compile the module statically into the kernel. > 2. Arrange for fuse service to be started prior to netmount (using say > /etc/conf.d/netmount rc_need="fuse") This doesn't sound right. Why does the kernel module need to be loaded explicitly? The kernel should auto-load the module when /dev/fuse is opened for the first time. /dev/fuse should get created via tmpfiles.d via kmod-static-nodes.
[gentoo-dev] Re: Re: Update on the 23.0 profiles
* "Andreas K. Huettel" <2862978.mvXUDI8C0e @pinacolada> : Wrote on Sun, 07 Apr 2024 15:27:42 +0200: >> I see no way of migrating to 23.0 profile because of not-recompilable >> packages that are installed (over 4 years) which block --emptytree, >> and do not wish to be forced to migrate to merged-usr on an openrc box >> without a compelling need (on principle). > That sounds a bit like self-inflicted pain. >> Will patching back the 17.0 profile files into the portage tree if and >> when they are removed work? > Unknown. > >> Are there any options at all for this situation (like freezing the the >> last supported tree protecting it from emerge-syncs, and using an >> overlay for further updates?) > > You can try to just skip these packages (with --exclude) during the > "emerge --emptytree ..." step. It should work, but no guarantees given. I switched the make.conf symlink (from portage/profiles/default/linux/amd64/17.1 to portage/profiles/default/linux/amd64/23.0/split-usr ) and the only difference in the emerge --info output is that LDFLAGS now additionally has "-Wl,-z,pack-relative-relocs" My use pattern is I'm only emerging packages by hand and setting useflags on a case by case basis. Also I have binpkgs going back to 5 years that I don't want to lose (by going to merged-usr, right now I can unpack and test these in a pinch). I also have various other packages outside the gentoo tree which depend on stuff which is not in gentoo portage anymore, which are really not rebuildable, but because of past portage flexibility multiple installed work fine and can be tested at the same time. The question is: Now if I don't attempt to do a rebuild and just update libtool and do further upgrades and installs on a case by case basis, it will will eventually pick up the new profile defaults. Is there any foreseeable downside to just doing this?
Re: [gentoo-dev] netmount and glusterfs (fuse) dependency management
Hi Joonas, Thanks for the below. Further comments there. On 2024/04/11 07:11, Joonas Niilola wrote: On 8.4.2024 12.51, Jaco Kroon wrote: In order for glusterfs to mount successfully the fuse module needs to be available when mount.glusterfs is invoked. This can be achieved in one of two ways: 1. Compile the module statically into the kernel. 2. Arrange for fuse service to be started prior to netmount (using say /etc/conf.d/netmount rc_need="fuse") 3. Add "/sbin/modprobe -q fuse" to the init.d file's start_pre() function, ExecStartPre with systemd, and make the ebuild warn about CONFIG_FUSE_FS with linux-info.eclass. 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). If you look at /etc/init.d/netmount it has some special logic in depend() to want nfsclient if (and only if) there is at least one filesystem with fs type nfs or nfs4. The logic for depending on /etc/init.d/fuse should be similar, but I don't think it makes sense to keep indefinitely expanding that depend() for every possible future filesystem that may have some special need like this. So I think what we should rather do is find all fstab entries with _netdev and !noauto's fstype, and iterate those and add the relevant want's from there (for openrc at least), in some mechanisms where packages other than openrc can *supply* the relevant dependency list (eg, glusterfs package would say that it want's net, dns and fuse). Something similar for systemd would be great, but I'd have to study up on systemd a bit before I can comment in greater detail. At an absolute minimum I think we should amend netmount to add "use fuse" such that if fuse is added to the relevant runlevels it will start before netmount (and then I an arrange that message be added to the glusterfs ebuild that fuse should be added to the default (where netmount is) runlevel). As it is one can rc_need=fuse in /etc/conf.d/netmount, or rc_use=fuse and add fuse to default runlevel, but I believe we can do better than either of these options. Kind regards, Jaco
Re: [gentoo-dev] netmount and glusterfs (fuse) dependency management
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. -- juippis OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] netmount and glusterfs (fuse) dependency management
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
