From wry+yaffs@ecoscentric.com Sat Jan 30 09:53:06 2010 Received: from hagrid.ecoscentric.com ([212.13.207.197] helo=mail.ecoscentric.com) by stoneboat.aleph1.co.uk with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NbA0j-0006eT-Fn for yaffs@lists.aleph1.co.uk; Sat, 30 Jan 2010 09:53:06 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id E476A2F7800C for ; Sat, 30 Jan 2010 09:52:54 +0000 (GMT) X-Virus-Scanned: amavisd-new at ecoscentric.com Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ju3QqrwRBOW; Sat, 30 Jan 2010 09:52:49 +0000 (GMT) Received: from [192.168.2.132] (60.66.187.81.in-addr.arpa [81.187.66.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: wry@ecoscentric.com) by mail.ecoscentric.com (Postfix) with ESMTP id 5A7082F7800A for ; Sat, 30 Jan 2010 09:52:49 +0000 (GMT) Message-ID: <4B64016E.6040905@ecoscentric.com> Date: Sat, 30 Jan 2010 09:52:46 +0000 From: Ross Younger User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: yaffs@lists.aleph1.co.uk References: <4B637D5B.80402@verizon.net> In-Reply-To: <4B637D5B.80402@verizon.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 212.13.207.197 X-SA-Exim-Mail-From: wry+yaffs@ecoscentric.com 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.6 required=4.5 tests=BAYES_00,SPF_PASS 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] YAFFS2 Memory Usage Redux 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: Sat, 30 Jan 2010 09:53:07 -0000 Chris wrote: > Is there any "low hanging fruit" to be had as far as compromising on > certain file system performance aspects, but gaining a much more > aggressive memory footprint? If you can accept the higher wastage you could move to larger virtual blocks: you could do this without touching the guts of the filesystem by creating a funky NAND driver which exposed a larger page size (say 8k or 16k, or perhaps even as large as a single eraseblock) to YAFFS. As every page of every file requires a Tnode entry, you've then at a stroke cut the number of entries required by a factor of four or eight. You've perhaps also shrunk the size of a single Tnode, and hence a few more bytes off every Tnode group of every file, if your NAND array had 2^16 or more physical pages. (This wouldn't help if your filesystem comprised mainly small files, as I think the per-object overhead would dominate?) Such a driver might conceivably be written as an intervening layer - that is to say, pretending to YAFFS to be an MTD device and itself talking to the real MTD device - which would I think be a good candidate to be contributed. Ross -- eCosCentric Ltd, Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK Registered in England no. 4422071. www.ecoscentric.com