Email list hosting service & mailing list manager

File type nomenclature in 170 Lassi Kortela (31 Jul 2020 11:11 UTC)
(missing)
Re: File type nomenclature in 170 Lassi Kortela (31 Jul 2020 11:44 UTC)
Re: File type nomenclature in 170 John Cowan (31 Jul 2020 15:21 UTC)
Re: File type nomenclature in 170 Lassi Kortela (31 Jul 2020 15:45 UTC)
Re: File type nomenclature in 170 hga@xxxxxx (31 Jul 2020 16:13 UTC)
Re: File type nomenclature in 170 Lassi Kortela (31 Jul 2020 16:25 UTC)
Re: File type nomenclature in 170 Lassi Kortela (31 Jul 2020 16:36 UTC)
Re: File type nomenclature in 170 hga@xxxxxx (31 Jul 2020 16:59 UTC)

Re: File type nomenclature in 170 hga@xxxxxx 31 Jul 2020 16:58 UTC

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Friday, July 31, 2020 11:36 AM
>
>> What you need to know in practice is which device driver a paticular
>> device node is using: disk, network, terminal, etc. And it varies by OS
>> whether e.g. a disk is a block or character device. On Linux the only
>> block devices left seem to be disks; on FreeBSD there are none.
>
> Here's the rundown from the FreeBSD handbook:
> <https://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-block.html>
>
>> 9.4. Block Devices (Are Gone)
>>
>> Other UNIX® systems may support a second type of disk device known
>> as block devices. Block devices are disk devices for which the
>> kernel provides caching. This caching makes block-devices almost
>> unusable, or at least dangerously unreliable. The caching will
>> reorder the sequence of write operations, depriving the application
>> of the ability to know the exact disk contents at any one instant
>> in time.
>>
>> This makes predictable and reliable crash recovery of on-disk data
>> structures (filesystems, databases, etc.) impossible. Since writes
>> may be delayed, there is no way the kernel can report to the
>> application which particular write operation encountered a write
>> error, this further compounds the consistency problem.
>>
>> For this reason, no serious applications rely on block devices, and
>> in fact, almost all applications which access disks directly take
>> great pains to specify that character (or “raw”) devices should
>> always be used. Because the implementation of the aliasing of each
>> disk (partition) to two devices with different semantics
>> significantly complicated the relevant kernel code FreeBSD dropped
>> support for cached disk devices as part of the modernization of the
>> disk I/O infrastructure.
>
> It sounds like block devices are only now used for disks, and the only
> reason you'd want to test for them is to avoid using them.

Which is an iron-clad case for keeping both predicates in the SRFI!

And I'll admit that OpenBSD is very old school with its single
file system type, which for me is tolerable, whereas FreeBSD famously
adopted ZFS.

But I have no objection to adding a predicate that checks both.

- Harold