From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vladislav Bolkhovitin Subject: Re: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS Date: Tue, 19 Jun 2007 18:00:22 +0400 Message-ID: <4677E176.5090102@vlnb.net> References: <20070612161029.GB28279@think.oraclecorp.com> <4676C2D6.8030708@vlnb.net> <46779DB1.7060807@draigBrady.com> <20070619120457.GD14108@think.oraclecorp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: =?ISO-8859-1?Q?P=E1draig_Brady?= , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org To: Chris Mason Return-path: Received: from mail-relay-02.mailcluster.net ([85.249.135.243]:50762 "EHLO mail-relay-02.mailcluster.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752246AbXFSOAf (ORCPT ); Tue, 19 Jun 2007 10:00:35 -0400 In-Reply-To: <20070619120457.GD14108@think.oraclecorp.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Chris Mason wrote: > On Tue, Jun 19, 2007 at 10:11:13AM +0100, P=E1draig Brady wrote: >=20 >>Vladislav Bolkhovitin wrote: >> >>>I would also suggest one more feature: support for block level >>>de-duplication. I mean: >>> >>>1. Ability for Btrfs to have blocks in several files to point to the >>>same block on disk >>> >>>2. Support for new syscall or IOCTL to de-duplicate as a single >>>transaction two or more blocks on disk, i.e. link them to one of the= m >>>and free others >>> >>>3. De-de-duplicate blocks on disk, i.e. copy them on write >>> >>>I suppose that de-duplication itself would be done by some user spac= e >>>process that would scan files, determine blocks with the same data a= nd >>>then de-duplicate them by using syscall or IOCTL (2). >>> >>>That would be very usable feature, which in most cases would allow t= o >>>shrink occupied disk space on 50-90%. >> >>Have you references for this number? >>In my experience one gets a lot of benefit from >>the much simpler process of "de-duplication" of files. >=20 >=20 > Yes, I would expect simple hard links to be a better solution for thi= s, > but the feature request is not that out of line.=20 From effort POV hard links could be a better solution, but from=20 effectiveness POV I can't agree with you. > I actually had plans > on implementing auto duplicate block reuse earlier in btrfs. >=20 > Snapshots already share duplicate blocks between files, and so all of > the reference counting needed to implement this already exists. > Snapshots are writable, and data mods are copy on write, and in gener= al > things work. >=20 > But, to help fsck, the extent allocation tree has a back pointer to t= he > inode that owns an extent. If you're doing snapshots, all of the own= ers > of the extent have the same inode number. If you're sharing duplica= te > blocks, the owners can have any inode number, and fsck becomes much m= ore > complex. >=20 > In general, when I have to decide between fsck and a feature, I'm goi= ng > to pick fsck. The features are much more fun, but fsck is one of the > main motivations for doing this work. I see. Thanks for explaining your position. Vlad - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html