public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Oliver Mattos <oliver.mattos08@imperial.ac.uk>
To: <btrfs-devel@arbitraryconstant.com>
Cc: Chris Mason <chris.mason@oracle.com>, <linux-btrfs@vger.kernel.org>
Subject: Re: Data De-duplication
Date: Wed, 10 Dec 2008 21:10:37 +0000	[thread overview]
Message-ID: <1228943437.7571.1.camel@mattos-laptop> (raw)
In-Reply-To: <32809.2001:470:e828:1::2:2.1228939660.squirrel@avalon.arbitraryconstant.com>

On Wed, 2008-12-10 at 13:07 -0700, Anthony Roberts wrote:
> > When the a direct read
> > comparison is required before sharing blocks, it is probably best done
> > by a stand alone utility, since we don't want wait for a read of a full
> > extent every time we want to write on.
> 
> Can a stand-alone utility do this without a race? Eg, if a portion of one
> of the files has already been read by the util, but is changed before the
> util has a chance to actually do the ioctl to duplicate the range.
> 
> If we assume someone is keeping a hash table of "likely" matches, might it
> make sense to have a verify-and-dup ioctl that does this safely?
> 

This sounds good because then a standard user could safely do this to
any file as long as he had read access to both files, but wouldn't need
write access (since the operation doesn't actually modify the file
data).


  parent reply	other threads:[~2008-12-10 21:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-09 22:48 Data De-duplication Oliver Mattos
2008-12-10 11:52 ` Miguel Figueiredo Mascarenhas Sousa Filipe
2008-12-10 13:30 ` Chris Mason
2008-12-10 17:53   ` Oliver Mattos
2008-12-11 15:12     ` Chris Mason
     [not found]   ` <32809.2001:470:e828:1::2:2.1228939660.squirrel@avalon.arbitraryconstant.com>
2008-12-10 21:10     ` Oliver Mattos [this message]
2008-12-10 21:19       ` Ray Van Dolson
2008-12-10 21:42         ` Oliver Mattos
2008-12-10 21:57           ` Tracy Reed
2008-12-10 22:06             ` Oliver Mattos
2008-12-10 22:10             ` Ray Van Dolson
2008-12-11  0:18               ` Oliver Mattos
2008-12-11  3:42                 ` Oliver Mattos
2008-12-11  3:50                   ` Ray Van Dolson
2008-12-11  9:58                     ` Oliver Mattos
2008-12-14 19:37                 ` Omen Wild
2008-12-14 12:25         ` Chris Samuel
2008-12-10 13:30 ` seth huang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1228943437.7571.1.camel@mattos-laptop \
    --to=oliver.mattos08@imperial.ac.uk \
    --cc=btrfs-devel@arbitraryconstant.com \
    --cc=chris.mason@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox