Date: Fri, 12 Jun 2020 09:20:18 +0200 From: Polytropon <freebsd@edvax.de> To: David Christensen <dpchrist@holgerdanske.com> Cc: freebsd-questions@freebsd.org Subject: Re: Bug or Feature? -- Disappearing /dev/ nodes after mount Message-ID: <20200612092018.2da920b8.freebsd@edvax.de> In-Reply-To: <01fb8c1e-a9e8-816e-a2ef-2c45c721687c@holgerdanske.com> References: <86546.1591917249@segfault.tristatelogic.com> <20200612082224.9c1e3797.freebsd@edvax.de> <01fb8c1e-a9e8-816e-a2ef-2c45c721687c@holgerdanske.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Jun 2020 23:54:55 -0700, David Christensen wrote: > On 2020-06-11 23:22, Polytropon wrote: > > On Thu, 11 Jun 2020 16:14:09 -0700, Ronald F. Guilmette wrote: > > >> Interestingly, as I have just learned, when and if the user subesquently > >> mounts the relevant partition, the corresponding `/dev/gpt/partname' node > >> will, rather unexpectedly and magically, disappear until such time as the > >> relevant partition is unmounted, whereupon it will reappear. > > >> 1) Is this behavior documented somewhere that I just failed to look at? > >> If so, where? > > > > Interesting question - I would be interested in that, too. > > See Lucas, AF3E, p. 214 "GEOM Withering" [1]. Wow, thanks for providing the term. techn. "GEOM Withering", which leads to usable search results, for example: This GEOM names appearing and disappearing is the consequence of *GEOM withering. A GEOM can be used in three different ways: - reading - writing - with exclusive access The latter is the cause of GEOM withering: once a disk is mounted an exclusive lock is required to inform the other available GEOM providers that the disk is in-use. GEOM therefore withers the other disk available names, that results in the names to disappear from the dev filesystem. For more information see g_wither_geom(9) and geom(4) ORPHANIZATION example. Source: https://fluca1978.github.io/2017/10/05/FreeBSD-Wither.html And from that point, local documentation at "man 4 geom" says: ORPHANIZATION is the process by which a provider is removed while it potentially is still being used. [...] When a provider is orphaned, this does not necessarily result in any immediate change in the topology: any attached consumers are still attached, any opened paths are still open, any outstanding I/O requests are still outstanding. with an explanation of what happens, with additional info found in "man 9 g_wither_geom". Today I learned. ;-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200612092018.2da920b8.freebsd>