On Mon, Apr 08, 2013 at 10:08:54PM +0800, Liu Bo wrote: > > Is it safe to use just 64 bits? I'd like to see better reasoning why > > this is ok. The limitation of btrfs_key to store only 1-2 64bit items is > > clear and must be handled, but it's IMO a critical design point. > > Actually I use the whole 256bit hash value(stored in its item) to avoid hash > collision, not just the stop 64bit.
Ok. It's good to point such things in the changelog/design docs, such things may not be immediatelly clear from the code. > > Last but not least, there was another dedup proposal (author CCed) > > > > http://thread.gmane.org/gmane.comp.file-systems.btrfs/21722 > > I waited for 2 months and wanted to see the actual code from the proposal, > but I > failed, so I decided to do it myself. Quoting from the mail: "My goal is to study Btrfs design, the offline deduplication patch [1] and to come up with a design for the online dedup, this semester. I will be implementing the feature next semester (spring, that is)." So the implementation starts about now ... > Anyway I'd like to see this feature in btrfs no matter who write it down. We'll end up with 2 implementations that are likely doing different tradeoffs and once one is merged the other one can be thrown away wasting time and efforts. Not my problem, but I don't uderstand why there's another implementation when the dedup project has been informally claimed (via mailinglist). david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
