newfs(1) on a file

[Nazim Can Bedir]

Linux is able to perform `swapon ./file`, FreeBSD isn't.

Then, go fuck and use Linux. No body gives a shit about you and your 
fucking preferred system. And, stay with Linux: asshole!

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.

Then, your problem is you are trying to live in a world where you don't 
understand. It doesn't work in real life, and it doesn't work in Unix 
either. So, go fuck yourself.


Did I say "Go fuck yourself, and never come back!"? Sorry, I am not 
smart enough.


If my country there is a saying: "If you know better, then prove it. At 
least, we can use the better one." Otherwise, shut the fuck up and find 
another list to shit-post! In this list, there is only one dick who can 
shit-post and guess who he is? So, seriously my friend, FUCK OFF!

Regards,
Nazim Can.


On 05/06/2020 00:14, goatshit54108 at national.shitposting.agency wrote:
> 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.
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"