MS Learn: Azure Blob Storage contradiction (190.7TiB vs. >5000 MiB)?

Question

As Bing AI reported about https://learn.microsoft.com/en-us/training/modules/explore-provision-deploy-non-relational-data-services-azure/2-azure-blob-storage:
"The phrase “giving a maximum size of over 5000 MiB” seems a bit confusing because it contradicts the earlier parts of the statement. If each block can hold 4000 MiB and you can have 50,000 blocks, that would indeed give you a total of 190.7 TiB, not 5000 MiB. It’s possible that there might be a mistake or misunderstanding in this part of the statement."

Is this a mistake? The 190.7 TiB is > 5000 MiB but that's an odd comparision.

Answer 1

Hello Rick Pack,

Thank you for posting your query here!

Block blobs are composed of blocks, each of which is identified by a block Id. Uploading a block is one operation and merging a set of blocks in order to form a blob is another. Each block can be up to 4000 MiB for Version 2019-12-12 and later and a block blob can include up to 50,000 blocks.

The maximum size of a block blob is therefore slightly more than 190.7 TiB (4000 MiB X 50,000 blocks).

However, if you are writing a block blob that is no more than 5000 MiB in size for Version 2019-12-12 and later, you can upload it in its entirety with a single write operation.

So, the maximum size of a block blob is slightly more than 190.7 TiB. However, “5000 MiB’ is the block blob limit that you can upload entirely with a single write operation (for latest version).

The following table describes the maximum permitted block and blob sizes, by service version:

For reference: https://learn.microsoft.com/en-us/rest/api/storageservices/understanding-block-blobs--append-blobs--and-page-blobs#about-block-blobs

Also, if you have any feedback on the document that you may want to provide, please click on feedback section of the document and submit your experience.

Do let us know if you have any further queries. I’m happy to assist you further.

Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

Hello Rick Pack 

Thank you for posting your query here!

Block blobs are optimized for uploading large amounts of data efficiently. Block blobs are composed of blocks, each of which is identified by a block ID. A block blob can include up to 50,000 blocks. Each block in a block blob can be a different size, up to the maximum size permitted for the service version in use. To create or modify a block blob, write a set of blocks via the Put Block operation and then commit the blocks to a blob with the Put Block List operation.

Block blobs store text and binary data. Block blobs are made up of blocks of data that can be managed individually. Block blobs can store up to about 190.7 TiB.

Blobs that are less than a certain size (determined by service version) can be uploaded in their entirety with a single write operation via Put Blob.

Storage clients default to a 128 MiB maximum single blob upload, settable in the Azure Storage client library for .NET version 11 by using the SingleBlobUploadThresholdInBytes property of the BlobRequestOptions object. When a block blob upload is larger than the value in this property, storage clients break the file into blocks. You can set the number of threads used to upload the blocks in parallel on a per-request basis using the ParallelOperationThreadCount property of the BlobRequestOptions object.

When you upload a block to a blob in your storage account, it is associated with the specified block blob, but it does not become part of the blob until you commit a list of blocks that includes the new block's ID. New blocks remain in an uncommitted state until they are specifically committed or discarded. There can be a maximum of 100,000 uncommitted blocks. Writing a block does not update the last modified time of an existing blob.

Block IDs are strings of equal length within a blob. Block client code usually uses base-64 encoding to normalize strings into equal lengths. When using base-64 encoding, the pre-encoded string must be 64 bytes or less. Block ID values can be duplicated in different blobs.

If you write a block for a blob that does not exist, a new block blob is created, with a length of zero bytes. This blob will appear in blob lists that include uncommitted blobs. If you don't commit any block to this blob, it and its uncommitted blocks will be discarded one week after the last successful block upload. All uncommitted blocks are also discarded when a new blob of the same name is created using a single step (rather than the two-step block upload-then-commit process).

Please let us know if you have any further queries. I’m happy to assist you further.

---

Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.