From manningc2@actrix.gen.nz Tue Jun 02 05:25:07 2009 Received: from smtp.firstline.co.nz ([203.167.210.162] helo=firstline.co.nz) by stoneboat.aleph1.co.uk with smtp (Exim 4.69) (envelope-from ) id 1MBLYZ-0006FO-Pq for yaffs@lists.aleph1.co.uk; Tue, 02 Jun 2009 05:25:07 +0100 Received: (qmail 26974 invoked by uid 453); 2 Jun 2009 04:24:48 -0000 X-Virus-Checked: Checked by ClamAV on firstline.co.nz Received: from Unknown (HELO linux-dual-head.local) (10.14.210.25) by firstline.co.nz (qpsmtpd/0.40) with ESMTP; Tue, 02 Jun 2009 16:24:48 +1200 From: Charles Manning To: yaffs@lists.aleph1.co.uk Date: Tue, 2 Jun 2009 16:24:46 +1200 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906021624.46957.manningc2@actrix.gen.nz> X-SA-Exim-Connect-IP: 203.167.210.162 X-SA-Exim-Mail-From: manningc2@actrix.gen.nz X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on stoneboat.aleph1.co.uk X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.2.5 X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on stoneboat.aleph1.co.uk) Subject: Re: [Yaffs] directory mtime update requires about 30% more I/O in postmark X-BeenThere: yaffs@lists.aleph1.co.uk X-Mailman-Version: 2.1.11 Precedence: list List-Id: Discussion of YAFFS NAND flash filesystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 04:25:07 -0000 It will depend very much on the types of application you're running. If your test is creating, renaming and deleting a lot, relative to other=20 operations then you will see the mtime change cause a lot more traffic sinc= e=20 a new directory record is being written on every cretion, rename or=20 deletion. If, however, your typical application tends to write fewer larger files (ie= =2E=20 mostly, say, 50k+) or update existing files then the effect will be dilute= d. =46rom what I have seen, postmark tries to simulate a large mail server (lo= ts of=20 small files) so this would be close to worst case scenario for yaffs. If this is a big issue I guess some heuristics could be applied to delay=20 writing the directories for mtimes. That way application like postmark woul= d=20 update the directory records less often. =2D- CHarles On Tuesday 02 June 2009 15:23:26 Karl wrote: > Hi, > > I run postmark on two versions of yaffs2, one with mtime update and one > without, with a modified nandsim, which records how many read/write/erase > during the test. The result shows that with the mtime update enabled, > yaffs2 needs about 30% more read/write/erase I/O in postmark. > > In yaffs without mtime update(more clearly, with yaffs_fs.c v1.80 in the > cvs repository, and yaffs_guts.c v1.82) the read/write/erase counting > result is: > > Read0 195328 ReadOOB 178371 Write0 357501 WriteOOB 0 Erase 3663 > > In yaffs with mtime update(yaffs_fs.c v1.81 and yaffs_guts.c v1.84), the > counting result is: > > Read0 288958 ReadOOB 178371 Write0 451131 WriteOOB 0 Erase 5047 > > Well, I have have no idea whether this will cause efficiency problems in > realworld applications. > > Here are the commands I run in postmark, with a 256MB MTD partition: > > set number 10000 > set transactions 50000 > set subdirectories 1000 > set buffering false > set seed 2 > run > > Karl > 2009.6.2 > > _______________________________________________ > yaffs mailing list > yaffs@lists.aleph1.co.uk > http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs