Date: Sun, 6 Mar 2016 20:19:49 +0000 (UTC) From: Jason Helfman <jgh@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r48349 - head/en_US.ISO8859-1/books/arch-handbook/driverbasics Message-ID: <201603062019.u26KJnfG014173@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: jgh Date: Sun Mar 6 20:19:49 2016 New Revision: 48349 URL: https://svnweb.freebsd.org/changeset/doc/48349 Log: - whitespace change only (translators may igore) Modified: head/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.xml Modified: head/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.xml Sun Mar 6 18:08:39 2016 (r48348) +++ head/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.xml Sun Mar 6 20:19:49 2016 (r48349) @@ -387,22 +387,20 @@ Closing device "echo".</screen> operations, depriving the application of the ability to know the exact disk contents at any one instant in time.</para> - <para> - 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.</para> + <para>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.</para> - <para> - 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 - <quote>raw</quote>) 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 &os; dropped support for cached disk + <para>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 <quote>raw</quote>) 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 &os; dropped support for cached disk devices as part of the modernization of the disk I/O infrastructure.</para> </sect1>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201603062019.u26KJnfG014173>