linux-kernel - Re: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <200706201118.03939.philipp.marek@bmlv.gv.at>
Date:	Wed, 20 Jun 2007 11:18:03 +0200
From:	"Ph. Marek" <philipp.marek@...v.gv.at>
To:	Vladislav Bolkhovitin <vst@...b.net>
Cc:	Philipp Matthias Hahn <pmhahn@...an.lahn.de>,
	Chris Mason <chris.mason@...cle.com>,
	Pádraig Brady <P@...igbrady.com>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS

On Mittwoch, 20. Juni 2007, Vladislav Bolkhovitin wrote:
> Philipp Matthias Hahn wrote:
> >>>>I would also suggest one more feature: support for block level
> >>>>de-duplication. I mean:
> So, seems ever for file based de-duplication some support from the FS,
> including some kind of ability for different inodes point to the same
> data blocks to store the meta-data, would be needed anyway.
The easy way is to have the inode point to a (shared, reference counted) data 
storage, which lists the data - then inodes can share the data, but have 
different meta-data.

Ever since I read about filesystems using the files' hash as addressing 
mechanism (per some Linus mail on LKML, about 10 years ago) and manber hashes 
(http://citeseer.ist.psu.edu/manber94finding.html) I'm thinking about various 
ways to use both in a filesystem.

Manber-Hashes allow to split data into similar chunks, which could be 
addresses per some cryptographic checksum, and used by several files.

*But*: The boundaries are not at power-of-2 addresses, so the data for 
read()/mmap() would have to be rebuild somehow. (Would eg. be necessary 
anyway if the data block itself is stored compressed).

The other question I'm still pondering ... File sizes vary very much. If I 
have a large project, eg. the kernel, with many thousand files of some 10 kB, 
some data could be shared - GPL licenses in files, #include lists, and some 
others.
If I have some other data, with files of several hundred megabytes, sharing 
gets more interesting ... but what should the right block size (for manber 
hashes) be? If it's small, we have to concatenate a lot of blocks to 
reconstruct data - if it's big, we might lose many chances for sharing.

And getting good performance, when blocks in the middle of a file have to be 
re-splitted, might be a bit of a problem, too ...

Regards,

Phil

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/