From owner-freebsd-arch@FreeBSD.ORG Tue Apr 1 20:20:20 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1E1F1065685 for ; Tue, 1 Apr 2008 20:20:20 +0000 (UTC) (envelope-from mfouts@danger.com) Received: from mx.danger.com (wall.danger.com [216.220.212.140]) by mx1.freebsd.org (Postfix) with ESMTP id D6F3F8FC27 for ; Tue, 1 Apr 2008 20:20:20 +0000 (UTC) (envelope-from mfouts@danger.com) Received: from danger.com (exchange3.danger.com [10.0.1.7]) by mx.danger.com (Postfix) with ESMTP id 5A5E8402FDF; Tue, 1 Apr 2008 13:20:11 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Apr 2008 13:20:19 -0700 Message-ID: In-Reply-To: <200804012010.m31KAMpu041011@apollo.backplane.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flash disks and FFS layout heuristics Thread-Index: AciUNGuMC9ZvsF/0TUeT8Q90DJXWjAAAFO/g References: <20080330231544.A96475@localhost> <200803310135.m2V1ZpiN018354@apollo.backplane.com> <200803312125.29325.qpadla@gmail.com> <200803311915.m2VJFSoR027593@apollo.backplane.com> <200803312219.m2VMJlkT029240@apollo.backplane.com> <200804011748.m31HmE1h039800@apollo.backplane.com> <200804012010.m31KAMpu041011@apollo.backplane.com> From: "Martin Fouts" To: "Matthew Dillon" Cc: freebsd-arch@freebsd.org Subject: RE: Flash disks and FFS layout heuristics X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2008 20:20:21 -0000 =20 > -----Original Message----- > From: Matthew Dillon [mailto:dillon@apollo.backplane.com]=20 > Sent: Tuesday, April 01, 2008 1:10 PM > To: Martin Fouts > Cc: freebsd-arch@freebsd.org > Subject: RE: Flash disks and FFS layout heuristics >=20 > 64MB is tiny. None of the problems with any of the=20 > approachs we've discussed even exist with devices that small in an=20 > embedded system. It is fairly clear that you're not familiar with NAND devices on embedded systems, as you've just said that well known problems do not exist. > To be clear, because I really don't understand how you=20 > can possibly argue that the named-block storage layer is bad in a=20 > device that small... Yes, your lack of understanding is very apparent. > It's seriously a non-issue. You are making too many=20 > assumptions about how named blocks would be used, particularly > if the filesystem is flash-aware. Now you're moving your goal posts. You came into this suggesting that the file system not be flash-aware. If I make the file system flash aware than many of the problems become managable. That *was* my starting thesis, after all. > Now, if you want to argue that this model would have=20 > serious performance penalities please go ahead, > I'm all ears. Feel free to implement it and see for yourself. The only point I had wished to make is that you get performance wins out of making the file system flash aware. Now that you've agreed to that, feel free to experiment with any of a number of ways of making it flash aware.