Subject: RE: NFSv4 Replication and Migration: design team conference call/ Draft

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 5 Jun 2002 15:17:25 -0700

> Clearly all the world's information is not represented
> by 2TB of data. 

Some random useless (and probably unreliable) information:

In last week's issue of Science there was a little piece
on considering the universe as a quantum computer.  They
had a statement that the universe as a whole contained 
10**120 bits of information while the sum of all computers
contained 10**21 bits of information.  Don't know how
they came up with these.  

-----Original Message-----
From: David Robinson [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 6:02 PM
To: Brent Callaghan
Cc: Robert Thurlow; Juan Gomez; [email-masked]
Subject: Re: NFSv4 Replication and Migration: design team conference
call/Draft

Brent Callaghan wrote:

> 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.

Be careful here, checksums are not generally designed to
uniquely identify a block, but to detect errors. As an
example, a 2TB storage device is all that is in theory needed
to return any 512 byte block based on a 32-bit checksum.
Clearly all the world's information is not represented
by 2TB of data. By the time you get to a high enough probability
of no error, the size of the checksum is large enough that
it is probably better to just use a lossless compression
algorithm.

	-David

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 5 Jun 2002 15:15:21 -0700

What is worthwhile depends on the environment.  I believe
the environment that the paper was talking about was that
of optimizing transmission over DSL.  This is an environment 
in which the bandwidths are low, so the cost of processing
all of the data you are sending is relatively low, while
the value of optimizing the use of very scarce bandwidth
is pretty high.

I think a considerable portion of the use of the migration 
and replication protocols usage is going to be within a
building in which the considerations are quite different.
There will be significant portion over distance so I don't
think we want to profligate with bandwidth, but I don't think
we will be seeing much use in very-low-bandwidth situations
so I think the first version at least should be oriented toward
optimizing TTWI (time-to-working-implementation) and we should
avoid going for anything fancy in the bandwidth optimization
area.

-----Original Message-----
From: Peter Staubach [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 5:14 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
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'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

---

From: "Juan Gomez" <[email-masked]>
Date: Wed, 5 Jun 2002 17:34:33 -0700

Alan,

I think you are right. The numbers about replication on filesystems that
were quite impressive (I think 25%+, If I remember correctly) were for
NTFS.
Not sure though, so I am contacting the person that mentioned this to me to
see if there are any public docs with this experimental information.

Juan

|---------+---------------------------->
|         |           "Yoder, Alan"    |
|         |           <[email-masked]> |
|         |                            |
|         |           06/05/02 05:22 PM|
|         |                            |
|---------+---------------------------->
  >------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                        |
  |       To:       Juan Gomez/Almaden/IBM@IBMUS, Brent Callaghan <[email-masked]>                                      |
  |       cc:       [email-masked], [email-masked], [email-masked]                  |
  |       Subject:  RE: NFSv4 Replication and Migration: design team conference call/       Draft                          |
  |                                                                                                                        |
  |                                                                                                                        |
  >------------------------------------------------------------------------------------------------------------------------|

If backing up desktop filesystems is envisioned
as a use of this protocol, then there is a huge
amount of replicated data out there.  I give you
Microsoft Office.

Alan

===============================================================
Alan G. Yoder                                    [email-masked]
Network Appliance, Inc.
Sunnyvale, CA                                      408-822-6919
===============================================================

> From: Juan Gomez [mailto:[email-masked]]
> Sent: Wednesday, June 05, 2002 5:07 PM
> To: Brent Callaghan
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Brent,
> This is in fact in the paper, I think the issue we need to
> weight is how
> often we use this in real life filesystems. The paper is
> focused on some
> very spciela cases that favor the algorithm.
> Perhaps we may run a replication search algorithm on
> filesystemns and find
> that similar blocks are only 1% and then this is a hopeless
> alternative. It
> would be nice if we could have estimates of replicated blocks in a
> filesystem we need to migrate and use our block-matching
> algorithm on cases
> where it is promissing to do so this may be another option to
> explore. I
> think the chunking/hashing algorithms proposed on the paper may cheap
> enough to predetermine block replication at a resonable CPU
> cost....all
> this we may want to explore.
>
>
> Juan
>
>
>
> |---------+---------------------------->
> |         |           Brent Callaghan  |
> |         |           <[email-masked]|
> |         |           m>               |
> |         |           Sent by:         |
> |         |           Brent.Callaghan@e|
> |         |           ng.sun.com       |
> |         |                            |
> |         |                            |
> |         |           06/05/02 02:12 PM|
> |         |                            |
> |---------+---------------------------->
>
> >-------------------------------------------------------------
> -----------------------------------------------------------|
>   |
>                                                              |
>   |       To:       Robert Thurlow
> <[email-masked]>
>                           |
>   |       cc:       Juan Gomez/Almaden/IBM@IBMUS,
> [email-masked]
>            |
>   |       Subject:  Re: NFSv4 Replication and Migration:
> design team conference call/Draft                                 |
>   |
>                                                              |
>   |
>                                                              |
>
> >-------------------------------------------------------------
> -----------------------------------------------------------|
>
>
>
>
>              Brent

---

From: "Juan Gomez" <[email-masked]>
Date: Wed, 5 Jun 2002 17:40:28 -0700

I do not agree with the second paragraph here. I think intersite
replication spanning WANs is an important area that should be considered in
NFSv4.
But I guess is to the group tpo define the span of this work, count my vote
on defining migration/replications that work efficiently over WANs.

Juan

|         |           "Noveck, Dave"   |
|         |           <Dave.Noveck@neta|
|         |           pp.com>          |
|         |           06/05/02 03:15 PM|
  |                                                                                                                        |
  |       To:       "'Peter Staubach'" <[email-masked]>, [email-masked], [email-masked]             |
  |       cc:       Juan Gomez/Almaden/IBM@IBMUS, [email-masked]                                             |
  |       Subject:  RE: NFSv4 Replication and Migration: design team conference call/       Draft                          |
  |                                                                                                                        |
  |                                                                                                                        |

-----Original Message-----
From: Peter Staubach [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 5:14 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: NFSv4 Replication and Migration: design team conference
call/Draft

                         ps

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 6 Jun 2002 07:02:32 -0700

It's just a question of degree.  Working as efficiently over WAN's 
as we can using well-established techniques is fine.  I just don't
want us to focus too much on this aspect.  You can save some bandwidth
with simple compression techniques, more with some less simple 
techniques, and even more with some interesting, neat, cool techniques.

I'd say we should be staying at the first of these stages, or the
beginnings of the second, at most.

-----Original Message-----
From: Juan Gomez [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 8:40 PM
To: Noveck, Dave
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: NFSv4 Replication and Migration: design team conference
call/ Draft

Juan

  |                                                                                                                        |

-----Original Message-----
From: Peter Staubach [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 5:14 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: NFSv4 Replication and Migration: design team conference
call/Draft

                         ps