From owner-freebsd-questions@freebsd.org Fri Jun 12 06:22:29 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 535CA330333 for ; Fri, 12 Jun 2020 06:22:29 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49jrHS3Lryz41N7 for ; Fri, 12 Jun 2020 06:22:28 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([178.8.39.138]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) with ESMTPA (Nemesis) id 1N6KpF-1iqZYG1Beb-016br3; Fri, 12 Jun 2020 08:22:25 +0200 Date: Fri, 12 Jun 2020 08:22:24 +0200 From: Polytropon To: "Ronald F. Guilmette" 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> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:NBbmugeZ27DsPgo1KvPMKTLNuZ9dLR5WU8zodxZRHKQGCnuYWtJ Jst8YwuQoqejnhvNib+urBFeUXtRLXVgiiV+QrhwTJP8CM1BmY+adcETfK7pHWyuMuuSWyW OJnjuAc8o35iIjIovX393A+zBnhUXE5inMXy3Wie+fQR+BDqpQkU/1CvaMHADl/TUXbSbx9 vs3OvqB2TcdiIiSeS/Mbw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:lIpbL/9IsBM=:AJbcLzvHIj/G7x+XJC9T1e ZjahwyRjO6PiV8zwEOeFdyoQKBucLtbm19Vwib3kM/f8BNq+toUaBVFRqp1r2JfZ8TBsUW3fL I7N9jmiMsOkV1JAZNP0eiFw4jd1npJT9c2BA4r0o1tpM8o+p8UVs5NLip3rqH1iUqsGpoODB9 gB68GTlyh44mT87sGccE/H1dE/wEzzbraKGdrG7sRSbaCkqd25yU/dpLEtAWMwXFhxCEeZa26 gnKHxG4AxePDW+f6/pjxVABvbanQMXPGEDuHXpg+o8yTizt0cddfiyKx/ryMZk0QFtQqiMjoe LWFm6FZR/lqq91fpuRjw+osziWCprL8bbANqGB7kaXWiq/qs7d7ab55nevubKlA465WeCtVkf xTfnC2RWOkdn0JB7g0CZtbTkGvvAy6CWaDvU4yzSDlA3IHaNsTy3SJjtoc3x0ss3KXW2XTY98 jsJCeKtKmWpsnh0MKRaiBhFP3s+TQJmr53Ic4q2CflN/w2Ps6g9W0e0qQVsbNagOKDJPExjrj vnFt/uj2C34T2k72k23sd0qtzXqs/4ojYoGMCpUhNXmP9RKDf1VhKl+hjk49WPcyHsBQFu4OV qAjTKnNazohK8LjNQ0APp6/yrIpTJQ4ikIcA7JqGqK8q1bfrVufAY0ZyL/vRH2zzIswgXhKCW NysOoir3ontuj9jGq5YCZTasd0OsQzD0CtviP6vNCikZAfeSqZoBO6IX9EFl2h1cbhg+eZ2JZ Bz1z6MuGwTEEuxFCyVRtNJC1vQ+C5dKghMTd+7kVvcEOkRnbcH/8G5a1OEVPwwTHhcgXObvwo GtHcHNqckqXFI2uAwsLckOO41D/tk8cO3QrA5JtAqNOpe4Ix80JR3W6sVfn0x8+AqWjiSu2 X-Rspamd-Queue-Id: 49jrHS3Lryz41N7 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@edvax.de has no SPF policy when checking 212.227.126.133) smtp.mailfrom=freebsd@edvax.de X-Spamd-Result: default: False [2.71 / 15.00]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_SHORT(-0.62)[-0.618]; RCPT_COUNT_TWO(0.00)[2]; RECEIVED_SPAMHAUS_PBL(0.00)[178.8.39.138:received]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_HAS_QUESTION(0.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.49)[0.488]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.44)[0.439]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[212.227.126.133:from]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.126.133:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 06:22:29 -0000 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 '. 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, ...