Date: Thu, 4 Jun 2020 21:14:11 +0000 From: goatshit54108@national.shitposting.agency To: freebsd-fs@freebsd.org Subject: Re: newfs(1) on a file Message-ID: <bb1b8bcf-14d6-59cc-efe4-c975aa8e1797@national.shitposting.agency> In-Reply-To: <8e221643-965c-3cbb-a043-4eed786c01e3@protonmail.com> References: <1d05302e-db7f-2538-16ee-dcd73c229e37@national.shitposting.agency> <8e221643-965c-3cbb-a043-4eed786c01e3@protonmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb1b8bcf-14d6-59cc-efe4-c975aa8e1797>