From owner-freebsd-fs@freebsd.org Thu Jun 4 21:14:27 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 5B90B3322C0 for ; Thu, 4 Jun 2020 21:14:27 +0000 (UTC) (envelope-from goatshit54108@national.shitposting.agency) Received: from mail.cock.li (mail.cock.li [37.120.193.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49dJSL13twz3gtp for ; Thu, 4 Jun 2020 21:14:25 +0000 (UTC) (envelope-from goatshit54108@national.shitposting.agency) Subject: Re: newfs(1) on a file DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=national.shitposting.agency; s=mail; t=1591305262; bh=ijpFJP2S0akwV+wLVYwEufEVaTCex9cgWlKbbRCXZeY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=eHGGdmNosDQkeuBIr+IarYsPFnlWzPA8bo2MJqtkDPJ0EnDMkDvlxRAvrhgyeFCRI b2FXdygvIeW7cFYFNk3xU6gJBEEJnXIsURGZUJWqQGdafBodpLRceB5+OdsoaeQuh2 NQBMxbqRxlItoKLNKmVgi31hwfTAV7q3zGgbybPrIH8fWDNDQNwdV9yfAzVSDX3b9i 9HrlfNRH64gYljb85NWGKw8oo5r34vtrsVY3WVpDc7q+OESj7o42zM72Qc4TG6sOQD xERW614fMqCnRF6cNPDS+LZs/BXjuvJqo3TkkfP9Wz5aCH8JjOP9nubdyqoVGC23KN pUuVXB5IjxDLA== To: freebsd-fs@freebsd.org References: <1d05302e-db7f-2538-16ee-dcd73c229e37@national.shitposting.agency> <8e221643-965c-3cbb-a043-4eed786c01e3@protonmail.com> From: goatshit54108@national.shitposting.agency Message-ID: Date: Thu, 4 Jun 2020 21:14:11 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.116 Safari/537.36 MIME-Version: 1.0 In-Reply-To: <8e221643-965c-3cbb-a043-4eed786c01e3@protonmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49dJSL13twz3gtp X-Spamd-Bar: +++++++++++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=national.shitposting.agency header.s=mail header.b=eHGGdmNo; dmarc=none; spf=fail (mx1.freebsd.org: domain of goatshit54108@national.shitposting.agency does not designate 37.120.193.124 as permitted sender) smtp.mailfrom=goatshit54108@national.shitposting.agency X-Spamd-Result: default: False [11.98 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; R_DKIM_ALLOW(0.00)[national.shitposting.agency:s=mail]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.99)[0.990]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[shitposting.agency]; NEURAL_SPAM_MEDIUM(1.00)[1.002]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; VIOLATED_DIRECT_SPF(3.50)[]; DKIM_TRACE(0.00)[national.shitposting.agency:+]; NEURAL_SPAM_LONG(0.99)[0.987]; FROM_NO_DN(0.00)[]; FORGED_MUA_MOZILLA_MAIL_MSGID_UNKNOWN(2.50)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; RBL_SENDERSCORE(2.00)[37.120.193.124:from]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:9009, ipnet:37.120.193.0/24, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; GREYLIST(0.00)[pass,meta] X-Spam: Yes 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 21:14:27 -0000 On 6/4/20 5:04 PM, Nazim Can Bedir via freebsd-fs wrote: > in order to include efficient and proper caching of disk > blocks into the equation, damn filesystem backing stores need to be > exist as devices. I find that hard to believe, at least with that exact wording. An alternative "Sorry, but all current FreeBSD-kernel filesystem-code is designed only with underlying block devices in mind, so some work is needed to handle other cases." sounds acceptable. The caching strategy mainly depends on the filesystem type, its implementation, and the settings. For some "filesystems", such as swap spaces, caching is specifically to be avoided. Linux is able to perform `swapon ./file`, FreeBSD isn't. > if mount command couldn't mount a GAY filesystem from the file > as-is, then newfs(8) command shouldn't allow to create filesystem on > file as-is (otherwise, idiot FreeBSD users like me could think that > "aah, if newfs initialises filesystem on file without md, then it must > be able to mount without md). But newfs *is* able to create a filesystem on a regular file. > I really don't understand what is the damn problem here? Filesystem > operations are performed on special files (a.k.a disks); and md kernel > driver does exist for that purpose. Again, I don't like this way of thinking. First, it goes again the Unix philosophy. Second, there is a clear separation between (a) creating, attempting to repair or debugging an instance of a filesystem, and (b) mounting a filesystem, thus connecting it to the kernel's filesystem-system -- a highly flammable area --, which practically assumes that the instance is well-formatted, and demands exclusive write access.