Google SoC idea

[Stephan Uphoff]

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