From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 8 18:05:50 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C541716A420 for ; Wed, 8 Jun 2005 18:05:50 +0000 (GMT) (envelope-from ups@tree.com) Received: from smtp.speedfactory.net (talon.speedfactory.net [66.23.216.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06BC043D55 for ; Wed, 8 Jun 2005 18:05:49 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 14116 invoked from network); 8 Jun 2005 19:01:45 +0000 Received: from 66-23-216-49.clients.speedfactory.net (HELO palm.tree.com) (66.23.216.49) by smtp.speedfactory.net with AES256-SHA encrypted SMTP; 8 Jun 2005 19:01:45 +0000 Received: from [127.0.0.1] (ups@localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id j58I5ipP086686; Wed, 8 Jun 2005 14:05:46 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Scott Long In-Reply-To: <42A6091C.40409@samsco.org> References: <42A475AB.6020808@fer.hr> <20050607194005.GG837@darkness.comp.waw.pl> <20050607201642.GA58346@walton.maths.tcd.ie> <42A6091C.40409@samsco.org> Content-Type: text/plain Message-Id: <1118253944.27369.35584.camel@palm> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 08 Jun 2005 14:05:44 -0400 Content-Transfer-Encoding: 7bit Cc: Pawel Jakub Dawidek , Scott Long , Ivan Voras , David Malone , hackers@freebsd.org, phk@freebsd.org Subject: Re: Google SoC idea X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2005 18:05:50 -0000 On Tue, 2005-06-07 at 16:52, Scott Long wrote: > David Malone wrote: > > On Tue, Jun 07, 2005 at 09:40:05PM +0200, Pawel Jakub Dawidek wrote: > > > >>+> Does it make sense to do it this way? Is it worth applying for the SoC? > >> > >>Not sure. Basically this is simlar what softupdate does, I think. > >>From another point of view softupdates are only available for UFS. > >>You probably wants to hear scottl and phk opinions (CCed). > > > > > > I think that Ivan's idea is kind of different from softupdates. His > > idea is pretty clever, in that it could provide synchronus random > > writes at sequential write speeds for any filesystem, providing you > > repaly the journal at startup. > > > > However, our main problem these days is the fact that we do an fsck > > after every unclean reboot, not the speed of writes. I guess that > > you could skip the fsck (or run it very slowly in the background) > > if you knew the filesystem was clean 'cos of jounral replay. > > > > David. > > /me jumps up and down and waves his hands > > The problem with journalling at the block layer is that you pretty much > become forced to journal metadata and data, since the block layer really > doesn't know the distinction, and definitely not in a > [ ... SNIP ...] In my opinion the original proposal described a non volatile write cache using dedicated cache disks. The proposed write cache implementation uses journaling. This does not offer additional guarantees to a file system and should not be confused with file system journaling / soft updates. Something like this has been on my wish list for a long time. A disk based write cache could easily accept short write bursts and reorder them later for more efficient writing (clustering?) to the final destination. ( Mirrored 15K SCSI write cache for big, fat slow RAID 5/6 SATA disk system) Support for nvram (micromemory comes to mind) cards would also be nice. Stephan