Linked by Thom Holwerda on Mon 2nd Nov 2009 23:20 UTC
ZFS has received built-in deduplication. "Deduplication is the process of eliminating duplicate copies of data. Dedup is generally either file-level, block-level, or byte-level. Chunks of data - files, blocks, or byte ranges - are checksummed using some hash function that uniquely identifies data with very high probability. Chunks of data are remembered in a table of some sort that maps the data's checksum to its storage location and reference count. When you store another copy of existing data, instead of allocating new space on disk, the dedup code just increments the reference count on the existing data. When data is highly replicated, which is typical of backup servers, virtual machine images, and source code repositories, deduplication can reduce space consumption not just by percentages, but by multiples."
Thread beginning with comment 392521
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: I skimmed the article...
by Tuxie on Tue 3rd Nov 2009 14:35
in reply to "RE[3]: I skimmed the article..."
Member since:2009-04-22
RE[5]: I skimmed the article...
by Laurence on Wed 4th Nov 2009 08:39
in reply to "RE[4]: I skimmed the article..."
Member since:2007-03-26
Well, why don't you just try it for yourself?
diff <(head -c 100000 file1.avi) <(head -c 100000 file2.avi)
This will compare the first 100000 bytes of file1.avi and file2.avi.
diff <(head -c 100000 file1.avi) <(head -c 100000 file2.avi)
This will compare the first 100000 bytes of file1.avi and file2.avi.
Unfortunately I'm moving house in a couple of days so my DVDs are packed away - thus I can't rip and diff. (though if anyone else is able to perform this test then i'd love to see the results)
....So I'm going to have to take your word on the differences being there.
However, (and going back to deduping for a moment) if understood the article properly, then the credits don't have to by byte for byte exact as the dedup looks at the bytes themselves rather than the whole MB block of bytes.
Thus there only has to be enough similar grouped bytes for a space saving to occure.
So unless MPEG compression uses some kind of random hash to encode it's data, then surely the very fact that the A/V is the same (timestamp or not) must mean that there are SOME similar bytes that can be grouped and indexed?
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2007-03-26
I guess that depends on the codec used.
I thought many MPEG codecs didn't have a timestamp as such and used a form of encoding that allowed an MPEG file (be it a video container file or an MP3 audio file) to be chopped in to parts at any random point and each of the parts can still play individually (much like the myth about worms ability to be chopped up and each part becoming alive)
Besides, your point is only valid for shows that have a pre-opening credits teaser rather than those (typically older) shows that always opened with music and credits.