From owner-freebsd-arch@FreeBSD.ORG Tue Apr 1 22:26:06 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 490FA106566C for ; Tue, 1 Apr 2008 22:26:06 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 279328FC21 for ; Tue, 1 Apr 2008 22:26:06 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m31MQ4Di042174; Tue, 1 Apr 2008 15:26:04 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m31MQ42O042173; Tue, 1 Apr 2008 15:26:04 -0700 (PDT) Date: Tue, 1 Apr 2008 15:26:04 -0700 (PDT) From: Matthew Dillon Message-Id: <200804012226.m31MQ42O042173@apollo.backplane.com> To: "Martin Fouts" 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> 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 22:26:06 -0000 :> 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. What complete bullshit. If you want to argue technical merits, be my guest. So far you haven't made one single technical point in any of your postings. You've posted about your experience with NAND flash in embedded systems, very clearly with SMALL flash devices and simple filesystems, and that's fine, it's similar to my flash filesystem experience (which, yes, was primarily on NOR devices but, no, that doesn't magically make you an expert on NAND and me an idiot about it). Considering I've pretty much spent my entire life working with hardware that is about as ridiculous an assertion as you could make, but clearly you believe it. But then you generalized to the entire market and that's not fine. Real filesystems are far more sophisticated then what you will ever see in the embedded flash product, and consequently real filesystems tend to broken down into more abstract terms so the higher layers can actually implement the filesystem functions without it taking 10 man years of programming. My interest is squarely with real filesystems targetted to mass storage, these days. I didn't start out smearing people, but if you are going to start acting like an asshole then I have no problem ratcheting it up to your level. :> 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. More bullshit. My first posting was not addressing performance issues, it was specifically addressing FFS and ZFS and the (bad) idea of making them more flash aware. ZFS on a 2G flash device? What the hell would be the point of that? We're talking about two completely different things. It used a NOR flash translation table by way of example. I sure as hell would never say that a flash-unaware filesystem would perform better then a flash-aware one. Duh! You have seriously misread the meaning behind that posting and you clearly didn't read any of the other postings. I suggest you go back and READ THE POSTINGS and maybe you'll start to understand the issues being addressed. Since you don't understand my position, let me lay it out for you in simple terms: * There's no point trying to adapt a flash-unaware filesystem to become flash-aware. It is a complete waste of time. You might as well write a new filesystem. If you want to use a flash-unaware filesystem you use a translation layer, eat any performance issues, and be done with it. MAYBE spend a few days optimizing the one or two critical paths you want to eek a little more performance out of. This has nothing to do with having to use translation tables and everything to do with the fact that the existance and use of those REQUIRED translation tables are not integrated into the flash-unaware filesystem, so inefficiencies are compounded rather then reduced. It's like jamming a square peg into a round hole. * Just because flash-unaware filesystems HAVE To use a translation layer doesn't mean that a translation layer is bad for a flash-aware filesystem. * A named-block translation layer can be an extremely valuable abstraction for use in filesystem designs which directly integrate its features (that is, the filesystem NAMES the block instead of ALLOCATES the block). There is absolutely NOTHING inherently bad about the model from a performance point of view, particularly if your storage media requires relocation (as NAND does). The key point is that a named-block layer takes over the functionality of all the indirect pointers that would normally have to be manipulated by higher layers in the filesystem. If you can integrate that into the physical storage requirements then you kill two birds with one stone and get major performance benefits from doing so. You are welcome to debate the points, but you'll get burned if you try to take some sort of moral highground stand based on a few piddly flash filesystems written over the course of a few years. Coding at that level is fun and interesting but ultimately not very difficult. :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. Right now my work is with HAMMER. It's fun to theorize how I could make HAMMER into a flash-aware filesystem but I have no intention of actually doing so any time soon, or ever. Frankly, if I wanted to write a ground-up flash filesystem I could, it would not be difficult... certainly not more difficult then HAMMER and HAMMER is probably the most sophisticated filesystem that exists in the open source world today. But I have no desire to do that at this juncture and the lack of desire certainly does not invalidate my comments on the matter. It's kinda like saying a person has no right to comment about how to cut an european apples if their focus in life is cutting american ones. NAND is different from NOR but the differences can be explained pretty much in two paragraphs and most of the same concepts apply. You can't byte-write, you have auxillary information, you need to add a little ECC, and scrub. It isn't rocket science. I am a very technical person. If you are going to argue merit, then you damn well better say WHY something doesn't work, in detail, instead of simply stating that someone random other entity couldn't make it work some point in the past so therefor it is bad. If you do not know the WHY, precisely, then good $#%$#%$#% luck designing anything that's actually sophisticated. -Matt Matthew Dillon