Date: Mon, 4 Mar 2002 17:58:12 +0100 (CET) From: Martin Heinen <martin@sumuk.de> To: FreeBSD-gnats-submit@freebsd.org Subject: docs/35539: [PATCH] config-tuning: clean up after revision 1.42 and 1.43 Message-ID: <200203041658.g24GwCT01187@sumuk.de>
next in thread | raw e-mail | index | archive | help
>Number: 35539 >Category: docs >Synopsis: [PATCH] config-tuning: clean up after revision 1.42 and 1.43 >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Mon Mar 04 09:00:02 PST 2002 >Closed-Date: >Last-Modified: >Originator: Martin Heinen >Release: FreeBSD 4.4-STABLE i386 >Organization: >Environment: System: FreeBSD Moses.earth.sol 4.4-STABLE FreeBSD 4.4-STABLE #0: Sat Dec 22 07:35:30 CET 2001 toor@Moses.earth.sol:/usr/obj/usr/src/sys/MOSES i386 >Description: removed a ) which was left over in revision 1.42, completed rename of i-node to inode (revision 1.43) >How-To-Repeat: read the section 'Tuning Disks' in the handbook >Fix: Index: chapter.sgml =================================================================== RCS file: /u/cvs/doc/en_US.ISO8859-1/books/handbook/config/chapter.sgml,v retrieving revision 1.44 diff -u -r1.44 chapter.sgml --- chapter.sgml 28 Feb 2002 22:38:15 -0000 1.44 +++ chapter.sgml 4 Mar 2002 16:06:20 -0000 @@ -923,13 +923,13 @@ their way out of the buffer cache onto the disk by the time of the crash, &man.fsck.8; is able to recognize this and repair the filesystem by setting the file length to - 0). Additionally, the implementation is clear and simple. + 0. Additionally, the implementation is clear and simple. The disadvantage is that meta-data changes are slow. An <command>rm -r</command>, for instance, touches all the files in a directory sequentially, but each directory change (deletion of a file) will be written synchronously to the disk. This includes updates to the directory itself, - to the i-node table, and possibly to indirect blocks + to the inode table, and possibly to indirect blocks allocated by the file. Similar considerations apply for unrolling large hierarchies (<command>tar -x</command>).</para> @@ -953,7 +953,7 @@ will be left in an unpredictable state. There is no opportunity to examine the state of the file system when the system comes up again; the data blocks of a file could already have - been written to the disk while the updates of the i-node + been written to the disk while the updates of the inode table or the associated directory were not. It is actually impossible to implement a <command>fsck</command> which is able to clean up the resulting chaos (because the necessary >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203041658.g24GwCT01187>