Date: Wed, 08 Jun 2005 14:05:44 -0400 From: Stephan Uphoff <ups@tree.com> To: Scott Long <scottl@samsco.org> Cc: Pawel Jakub Dawidek <pjd@freebsd.org>, Scott Long <scottl@freebsd.org>, Ivan Voras <ivoras@fer.hr>, David Malone <dwmalone@maths.tcd.ie>, hackers@freebsd.org, phk@freebsd.org Subject: Re: Google SoC idea Message-ID: <1118253944.27369.35584.camel@palm> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1118253944.27369.35584.camel>