On Wed, Dec 7, 2011 at 9:58 AM, Ignatios Souvatzis <pre...@ycm-bonn.de> wrote: > On Tue, Dec 06, 2011 at 12:44:16PM -0500, Donald Allen wrote: >> On Tue, Dec 6, 2011 at 11:58 AM, Thor Lancelot Simon <t...@panix.com> wrote: >> > On Tue, Dec 06, 2011 at 11:10:44AM -0500, Donald Allen wrote: >> >> >> >> 2. I'm a little bit surprised that the filesystem was as much of a >> >> mess as it was. >> > >> > I'm not. You mounted the filesystem async and had a crash. With the >> > filesystem mounted async *nothing* pushes out most metadata updates, >> > with the result that the filesystem's metadata can quickly enter a >> > fatally inconsistent state. The only way home safe is a clean unmount. >> >> So unwritten meta-data from an async filesystem can sit in the buffer >> cache for arbitrarily long periods of time in NetBSD? I just want to >> be sure I understand what you are saying. Because that essentially >> guarantees, as you imply above, that if the system crashes, you will >> lose the filesystem. That makes the following warning, in the mount(8) >> man page, in the description of the async option: >> >> "In the event of a crash, it is impossible for the system to verify >> the integrity of data on a file system mounted with this option." >> >> much more clear. When I read this before the fun started, I took it to > > You left out part of the warning. From NetBSD 5.1: > > async All I/O to the file system should be done asyn- > chronously. In the event of a crash, it is > impossible for the system to verify the integrity of > data on a file system mounted with this option. You > should only use this option if you have an applica- > tion-specific data recovery mechanism, or are willing > to recreate the file system from scratch. > > Isn't the last sentence of that paragraph in your version?
No. My version says "If you use this option and the system crashes, everything will be fine." /Don
