# Shredded storage does not work

We've upgraded to SP2016 from SP2010. One of the key features we are interested in is Shredded Storage as we've got a lot of metadata updates that in SP2010 would cause a lot of waste of storage.

However, we've found out that updating metadata of an item in SP2016 still seems to store the entire blob again.

1. Uploaded a 10kb XML file
2. Checked $site.Usage.Storage 3. Updated metadata of the file 4.$site.Usage.Storage is now ~10kb more.

How is this possible? Or does this only work for Word documents...?

Shredded Storage is built to split bigger files into chunks. If you upload another version of the same document, only the differencing chunks will get updated in the content database.

The default size of a chunk is 64KB. If you do a change to a document, the smallest possible change is about 64KB. So you shouldn't try to measure the efficiency of Shredded Storage with a 10KB file.

If you only work with that small files, Shredded Storage won't help you decrease your storage needs. You could reduce the chunk size as described in the article, but the metadata overhead will reduce the efficiency as your ChunkSize decreases.

Some SQL-Information from a fresh uploaded document with ~900KB (5 Shreds):

And now the number of Shreds after only updating the "title" in SharePoint:

• But my understanding is, that if I only update the metadata (so via Edit Properties), no chunk is stored at all? Or am I mistaken? In our case, we never update the document, we only update the metadata after uploading. – Boland Jan 8 '18 at 21:06
• Updating Metadata creates another version of the document, so at least one Shred is created. – MHeld Jan 9 '18 at 13:36
• are you sure? E.g. here it says "Similarly, if a user updates only metadata for an Office document, and not the document itself, there is a storage benefit. In SharePoint 2010, updating a column in a document library (which effectively creates a new version of the document) creates a copy of the document BLOB even if the document itself was not updated. With shredded storage, there is no change to the document, so there are no shreds added. Only metadata changes." itprotoday.com/sharepoint-2013-shredded-storage-and-end-world – Boland Jan 9 '18 at 19:46
• And here: In case of an update that only includes meta-data changes, the number of changed shreds is basically zero which means that no new BLOBs are written to SQL and the shred-index for the new version is the same as the previous one. informedconsulting.nl/blog/… – Boland Jan 9 '18 at 19:50
• And just did a quick test with a 9MB file. After updating the title metadata property, the size storage has increased by 9MB... # s is an SPSite object (Get-SPSite $s.Url).Usage.Storage -$s.Usage.Storage 0 $item["Title"] = "testlargeupdated"$item.Update() (Get-SPSite $s.Url).Usage.Storage -$s.Usage.Storage 9427722 – Boland Jan 9 '18 at 20:04

Shredded storage works on all document types, though not all types as effectively as Office documents. Shredded storage cannot be disabled and will always be used.

That said, the sproc and tvf are quite complex to calculate out this storage. It may be that it simply pulls the full size of the item for each version, as that is what you'd need if you were going to export each version out of SharePoint onto a file system.

• Hi Trevor, thank you for your reply. It's not just this small test I've done, we've seen on production that the content size is growing just as fast as in SP2010. We've got scripts that removes versions, and it's releasing a lot of space when run. So it seems that shredded storage doesn't work in our case. We're only updating metadata for documents.... – Boland Jan 8 '18 at 2:20