Date: Fri, 12 Jun 2020 08:22:24 +0200 From: Polytropon <freebsd@edvax.de> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-questions@freebsd.org Subject: Re: Bug or Feature? -- Disappearing /dev/ nodes after mount Message-ID: <20200612082224.9c1e3797.freebsd@edvax.de> In-Reply-To: <86546.1591917249@segfault.tristatelogic.com> References: <86546.1591917249@segfault.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Jun 2020 16:14:09 -0700, Ronald F. Guilmette wrote: > If a disk device which has been partitioned using GPT partitioning exists > and is powered on and is installed in a given system, and if there exists > on that disk device a GPT partition which had been given the GPT partition > name `partname' then a character special device node representing that > specific partition will normally appear, automagically, underneath the > /dev/gpt/ directory. The node in question will have the name > `/dev/gpt/partname' > > 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. That is correct. The "provider" for a storage resource, to borrow from GEOM terminology, has been consumed, so the corresponding device file is no longer present. However, if you issue commands like "mount" or "df", you'll still be able to see its name. The disk device file name of course is still present, so if you have /dev/ada0p1 which is /dev/gpt/data, and you do "mount -t ufs /dev/gpt/data /mnt", then /dev/gpt/data will disappear (provider consumed), but /dev/ada0p1 is still there (and allowing you to perform specific low-level "sub-FS" disk operations). If you then see "mount -v", you will see the label name in there. > Despite having looked over several of the arguably relevant man pages, > I have not found any place where this specific bit of automagical kernel > behavior is documented. Thus, I am left with questions: > > 0) Am I the only one who has observed this specific behavior? No, it is normal and expected. > 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. > 2) Is there a consensus that the magical disappearance of /dev/gpt/ device > nodes during times when the corresponding partition is mounted represents > a feature, rather than a bug? As I said, it's normal, and it doesn't just apply to GPT labels, but if I remember correctly, to _all_ labels, such as UFS labels (/dev/ufs/*) and glabel labels (/dev/label/*), maybe even to UFSIDs (/dev/ufsid/*). > P.S. Despite the occasional disappearance of /dev/gpt/ device nodes, > as described above, a complete listing of all of the GPT partitions, > irrespecitive of their mount status, along with their respective labels, > is still always available via `gpart show -l <device>'. The `glabel list' > command also shows all relevant partitions and their GPT lables, once > again, irrespective of the mount status of any of the relevant partitions. Correct. > P.P.S. I have not checked, but it is my assumption that this disappearing > /dev/ node "feature" likely also affects device nodes that get automagically > created underneath any of the other /dev/ subdirectories listed in the > glabel(8) man page. Yes, I think this assumption is true for all labeling mechanisms. And /dev/cpu0: device disappeared. ;-) -- 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?20200612082224.9c1e3797.freebsd>