Date: Sun, 22 Jan 2017 08:02:34 +0000 From: "Poul-Henning Kamp" <phk@freebsd.org> To: John-Mark Gurney <jmg@funkthat.com> Cc: Aijaz Baig <aijazbaig1@gmail.com>, "Greg 'groggy' Lehey" <grog@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, freebsd-scsi@freebsd.org Subject: Re: Understanding the rationale behind dropping of "block devices" Message-ID: <74696.1485072154@critter.freebsd.dk> In-Reply-To: <20170121235131.GF1768@funkthat.com> References: <CAHB2L%2BdRbX=E9NxGLd_eHsEeD0ZVYDYAx2k9h17BR0Lc=xu5HA@mail.gmail.com> <20170116071105.GB4560@eureka.lemis.com> <CAHB2L%2Bd9=rBBo48qR%2BPXgy%2BJDa=VRk5cM%2B9hAKDCPW%2BrqFgZAQ@mail.gmail.com> <20170121235131.GF1768@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--------
In message <20170121235131.GF1768@funkthat.com>, John-Mark Gurney writes:
>Aijaz Baig wrote this message on Mon, Jan 16, 2017 at 14:19 +0530:
>> Nevertheless my question still holds. What does 'removing support for b=
lock
>> device' mean in this context? Was what I mentioned earlier with regards=
to
>> my understanding correct? Viz. all disk devices now have a character (o=
r
>> raw) interface and are no longer served via the "page cache" but rather=
the
>> "buffer cache". Does that mean all disk accesses are now direct by pass=
ing
>> the file system??
>
>One of the other reasons block devices were removed was that if there
>was a write error on the underlying device, there was no way for the
>writer to know that the write failed. This could/would lead to corrupted
>data which is bad.
This paper hopefully answers a lot of the questions:
https://www.usenix.org/conference/bsdcon02/rethinking-dev-and-devices-=
unix-kernel
-- =
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe =
Never attribute to malice what can adequately be explained by incompetence=
.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?74696.1485072154>