[src/trunk]: src/share/man/man9 Explain wapbl's relation to the garbage-appen...

[riastradh <riastradh%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/322cd53688ba
branches:  trunk
changeset: 807075:322cd53688ba
user:      riastradh <riastradh%NetBSD.org@localhost>
date:      Fri Mar 27 19:58:58 2015 +0000

description:
Explain wapbl's relation to the garbage-appendage bug.

diffstat:

 share/man/man9/wapbl.9 |  22 +++++++++++++++++++++-
 1 files changed, 21 insertions(+), 1 deletions(-)

diffs (36 lines):

diff -r 4f12d301f90c -r 322cd53688ba share/man/man9/wapbl.9
--- a/share/man/man9/wapbl.9    Fri Mar 27 19:48:37 2015 +0000
+++ b/share/man/man9/wapbl.9    Fri Mar 27 19:58:58 2015 +0000
@@ -1,4 +1,4 @@
-.\"    $NetBSD: wapbl.9,v 1.4 2015/03/27 19:48:37 riastradh Exp $
+.\"    $NetBSD: wapbl.9,v 1.5 2015/03/27 19:58:58 riastradh Exp $
 .\"
 .\" Copyright (c) 2015 The NetBSD Foundation, Inc.
 .\" All rights reserved.
@@ -426,6 +426,26 @@
 .Xr ubc_uiomove 9 ,
 which is normally used for file data.
 .Pp
+Not only is
+.Nm
+unable to log writes via the page cache, it is also unable to defer
+.Xr buffercache 9
+writes until cached pages have been written.
+This manifests as the well-known garbage-data-appended-after-crash bug
+in FFS: when appending to a file, the pages containing new data may not
+reach the disk before the inode update reporting its new size.
+After a crash, the inode update will be on disk, but the new data will
+not be -- instead, whatever garbage data in the free space will appear
+to have been appended to the file.
+.Nm
+exacerbates the problem by increasing the throughput of metadata
+writes, because it can issue many metadata writes asynchronously that
+FFS without
+.Nm
+would need to issue synchronously in order for
+.Xr fsck 8
+to work.
+.Pp
 There is only one
 .Nm
 transaction for each file system at any given time, and only one