From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans Reiser Subject: Re: fsync() Performance Issue Date: Mon, 06 May 2002 17:02:40 +0400 Message-ID: <3CD67EF0.9090100@namesys.com> References: <93F527C91A6ED411AFE10050040665D0049BF9B4@corpusmx1.us.dg.com> <1020463205.3 946.252.camel@tiny> <3CD341EC.9080906@namesys.com> <1020517884.3947.266.camel@tiny> <3CD3F76D.4000708@namesys.com> <1020688827.3947.2087.camel@tiny> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Chris Mason Cc: berthiaume_wayne@emc.com, reiserfs-list@namesys.com, green@namesys.com Chris Mason wrote: >On Sat, 2002-05-04 at 10:59, Hans Reiser wrote: > > >>So how about if you revise fsync so that it always sends data blocks to >>the journal not to the main disk? >> >> > >This gets a little sticky. > >Once you log a block, it might be replayed after a crash. So, you have >to protect against corner cases like this: > >write(file) >fsync(file) ; /* logs modified data blocks */ >write(file) ; /* write the same blocks without fsync */ >sync ; /* use expects new version of the blocks on disk */ > > >During replay, the logged data blocks overwrite the blocks sent to disk >via sync(). > >This isn't hard to correct for, every time a buffer is marked dirty, you >check the journal hash tables to see if it is replayable, and if so you >log it instead (the 2.2.x code did this due to tails). This translates >to increased CPU usage for every write. > Significant increased CPU usage? > >I'd rather not put it back in because it adds yet another corner case to >maintain for all time. Most of the fsync/O_SYNC bound applications are >just given their own partition anyway, so most users that need data >logging need it for every write. > most users don't know enough to turn it on....;-) > >-chris > > > > > > > >