[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Lost file-system story
On Wed, Dec 7, 2011 at 9:58 AM, Ignatios Souvatzis
> 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
>> <tls%panix.com@localhost> 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."
Main Index |
Thread Index |