From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans Reiser Subject: Re: Was able to reproduce "cp: cannot stat file.x: Input/output error" Date: Tue, 10 Aug 2004 12:55:27 -0700 Message-ID: <4119282F.2000603@namesys.com> References: <20040807065039.5BF4E15CBC@mail03.powweb.com> <41148997.4070404@namesys.com> <200408100321.i7A3LHxu027087@turing-police.cc.vt.edu> <20040810092022.GN9811@backtop.namesys.com> <4119077E.6070306@namesys.com> <20040810180515.GR9811@backtop.namesys.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <20040810180515.GR9811@backtop.namesys.com> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Alex Zarochentsev Cc: Valdis.Kletnieks@vt.edu, David Dabbs , 'ReiserFS List' Alex Zarochentsev wrote: >On Tue, Aug 10, 2004 at 10:35:58AM -0700, Hans Reiser wrote: > > >>Alex Zarochentsev wrote: >> >> >> >>>On Mon, Aug 09, 2004 at 11:21:17PM -0400, Valdis.Kletnieks@vt.edu wrote: >>> >>> >>> >>> >>>>On Sat, 07 Aug 2004 00:49:43 PDT, Hans Reiser said: >>>> >>>> >>>> >>>> >>>> >>>>>>I think I have discovered the problem - unless there was a reason mongo >>>>>>was >>>>>>issuing mount/unmount commands at the start/end of a mongo 'run' as >>>>>>well as >>>>>>before/after _each phase_. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>Probably someone wanted to separate the measurement of the phases. It >>>>>has been a while since I read mongo..... >>>>> >>>>> >>>>> >>>>> >>>>Note that an unmount/mount pair will force a flush of all dirtied pages >>>>in the >>>>in-memory file cache, and *really* not return until it's really done and >>>>really >>>>out on disk. In addition, sync() will force stuff to disk, but *not* >>>>invalidate >>>>in-cache pages - more drastic measures are needed if you want to benchmark >>>>with a cold cache (which is almost a must if you're doing actual >>>>filesystem >>>>benchmarking, as otherwise you're benching the in-core cache instead). >>>> >>>> >>>> >>>> >>>That was designed to have result in each phase as independent as we can. >>>For >>>example, if we have read slowdown in mongo, we will analyze only reads and, >>>probably, fs fragmentation, we won't deal with unmeasurable cache state >>>before >>>the read phase. Known and persistent "cold cache effect" is better than >>>unknown >>>hot cache one :) And, mongo phases are designed to be long and keep the >>>cold >>>cache effect at minimum. >>> >>> >>> >>> >>Let me be more precise here. Is the time spent mounting and umounting >>included in the time for the phase? >> >> > >oops. sync time included. mount/umount time is not. > > > > You see the problem, yes? Your suggestion?