From: Peter Staubach (Peter.Staubach@sun.com)
Date: 06/05/02-04:13:39 PM Z
Message-Id: <200206052116.g55LG3126134@amunet.Central.Sun.COM> Date: Wed, 5 Jun 2002 15:13:39 -0600 (MDT) From: Peter Staubach <Peter.Staubach@sun.com> Subject: Re: NFSv4 Replication and Migration: design team conference call/Draft > > > I think compression could be worthwhile to explore. It's not clear > > that we can take advantage of similar blocks except for blocks of > > zeros, which we should certainly optimize. What amount of block > > replication would you expect, and under what circumstances? > > I'm not sure if I read it in the paper Juan referenced, but > you could in theory avoid some data transfers if you kept > track of each block of transferred data together with a > checksum. > > Then when you need to transfer a block of new data in > a file, you checksum the block and see if you've transferred > it previously as part of another file. If you get a hit, > then instead of transferring the block, you just tell the > other end where it is, and where it needs to go. > > I've no idea whether this happens often enough to be > worthwhile - maybe I should go back and read Maziere's paper > again ... > Between this and the sparse file detection, the cpu overheads are possibly starting to become significant. Looking at a block to see whether it is all zeros is really expensive. There needs to be a cheaper way. This also doesn't match real life semantics. We will need to be able to replicate files created with mkfile(1M) for example. They tend to be populated with zeros, but are fully populated for good reasons. A block of zeros does not mean that the block is not populated. ps
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:48 AM Z CST