From owner-freebsd-fs@freebsd.org Thu Jun 4 17:04:41 2020 Return-Path: Delivered-To: freebsd-fs@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 903E732A0E0 for ; Thu, 4 Jun 2020 17:04:41 +0000 (UTC) (envelope-from nzmjx@protonmail.com) Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49dBw84B5wz4Jpl for ; Thu, 4 Jun 2020 17:04:40 +0000 (UTC) (envelope-from nzmjx@protonmail.com) Date: Thu, 04 Jun 2020 17:04:31 +0000 To: freebsd-fs@freebsd.org From: Nazim Can Bedir Reply-To: Nazim Can Bedir Subject: Re: newfs(1) on a file Message-ID: <8e221643-965c-3cbb-a043-4eed786c01e3@protonmail.com> In-Reply-To: <1d05302e-db7f-2538-16ee-dcd73c229e37@national.shitposting.agency> References: <1d05302e-db7f-2538-16ee-dcd73c229e37@national.shitposting.agency> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HK_RANDOM_REPLYTO shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 49dBw84B5wz4Jpl X-Spamd-Bar: - X-Spamd-Result: default: False [-1.74 / 15.00]; HAS_REPLYTO(0.00)[nzmjx@protonmail.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[protonmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.88)[-0.884]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.22:from]; NEURAL_HAM_MEDIUM(-0.08)[-0.083]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; DKIM_TRACE(0.00)[protonmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; NEURAL_SPAM_SHORT(0.32)[0.325]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.22:from] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 17:04:41 -0000 Or, The normal file I/O and device I/O call and code paths in the kernel are=20 different. And, in order to include efficient and proper caching of disk=20 blocks into the equation, damn filesystem backing stores need to be=20 exist as devices. And, contrary to common belief, FreeBSD kernel=20 developers may not be smart enough as you because they followed the sane=20 approach: if mount command couldn't mount a GAY filesystem from the file=20 as-is, then newfs(8) command shouldn't allow to create filesystem on=20 file as-is (otherwise, idiot FreeBSD users like me could think that=20 "aah, if newfs initialises filesystem on file without md, then it must=20 be able to mount without md). I really don't understand what is the damn problem here? Filesystem=20 operations are performed on special files (a.k.a disks); and md kernel=20 driver does exist for that purpose. On 04/06/2020 19:39, goatshit54108@national.shitposting.agency wrote: > Running newfs(1) on a regular file bumps into some GAY issues: > > $ dd status=3Dnone if=3D/dev/zero bs=3D1m count=3D4 of=3Dshit > $ newfs ./shit > newfs: ./shit: not a character-special device: No error: 0 > newfs: no valid label found > > The message is not clear, but it happens to be a cry for a BSD label. OK,= first creating a BSD label does allow newfs to succeed: > $ bsdlabel -wf ./shit > $ newfs ./shit > newfs: ./shit: not a character-special device: No error: 0 > ... (creation OK) > > The bump is inside getdisklabel(). Patching out the one and only call to = getdisklabel() seems to avoid the issue without negative consequences: > =09... > =09lp =3D NULL; //lp =3D getdisklabel(); // GAY > =09... > > $ dd status=3Dnone if=3D/dev/zero bs=3D1m count=3D4 of=3Dshit > $ non-gay_newfs ./shit > newfs: ./shit: not a character-special device: No error: 0 > preposterous size 0 > $ non-gay_newfs -s $(((4 << 20) / 512)) ./shit > newfs: ./shit: not a character-special device: No error: 0 > ... (creation OK) > > The inconvenient alternative, to get newfs to format the file though a me= mory disk, appears to create an identical file: > $ dd status=3Dnone if=3D/dev/zero bs=3D1m count=3D4 of=3Dshit > $ su root > ... (GAY) ... > # mdconfig -a -t vnode -f ./shit -u 9 > # newfs /dev/md9 > ... (creation OK) ... > > Identical, that is, if we use `newfs -R` and discount a couple of reprodu= cibility bugs/issues (, ). > > Also, at a glance, using the BSD label method yields nothing other than a= UFS filesystem along with a BSD label. > > So this code appears to be old garbage. > > Furthermore, the "not a character-special device" warning is just GAY wit= hout any benefit. > > Or?... > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"