From manningc2@actrix.gen.nz Fri Mar 12 03:14:07 2010 Received: from smtp.firstline.co.nz ([203.167.210.162] helo=scorch.co.nz) by stoneboat.aleph1.co.uk with smtp (Exim 4.69) (envelope-from ) id 1NpvK4-0004P6-52 for yaffs@lists.aleph1.co.uk; Fri, 12 Mar 2010 03:14:07 +0000 Received: (qmail 16117 invoked by uid 453); 12 Mar 2010 03:13:47 -0000 X-Virus-Checked: Checked by ClamAV on scorch.co.nz Received: from Unknown (HELO linux-dual-head.local) (10.14.210.25) by scorch.co.nz (qpsmtpd/0.40) with ESMTP; Fri, 12 Mar 2010 16:13:47 +1300 From: Charles Manning To: yaffs@lists.aleph1.co.uk Date: Fri, 12 Mar 2010 16:13:45 +1300 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201003121613.45921.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=-1.9 required=4.5 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: [Yaffs] More yaffs speed ups 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: Fri, 12 Mar 2010 03:14:07 -0000 Hi All This week has been good for speeding up yaffs. All cchanges mentioned here are now in cvs. As mentioned earlier this week, the dynamic updating of the oldest dirty sequence number sped up writes by up to 30% for one cell phone platform. Then there was the addition of background processing for dirty directory handling. That can reduce the writes associated with small file creation/deletion by a significant amount meaning less garbage collection and faster performance. Today has seen two further check ins that give speed ups: A) Phase 1 of reduction of shrink headers Shrink headers are no longer written when files are resized down or overwritten. This can significantly reduce the number of shrink headers which can really make a big difference to garbage collection speed. Shrink headers are still written when files are resized up by large amounts or when a file is deleted. One particular scenario that this helps is where files are opened for write with O_TRUNC and completely overwritten. eg. #cp a foo #cp b foo That would have created a shrink header in the past but no longer does. B) Better block iteration There are some code sequences that iterated over all blocks and called the yaffs_GetBlockInfo() function. These now just use direct block iteration which is way faster. The difference will likely not be anything as dramatic as other improvements, but it is there. All my test harnesses will be running for the whole week end to give these changes a thorough work out. Friday afternoon here... time to go fishing. -- Charles