Lista bloków blob Azure jest pusta, ale blob nie jest pusty! Jak to może być?

Question

Problem w skrócie:

Blok blob może być utworzony z pojedynczego żądania PUT. Spowoduje to utworzenie obiektu typu blob z zatwierdzoną zawartością, ale obiekt blobowy nie będzie miał żadnych zatwierdzonych bloków!

Oznacza to, że nie można założyć, że łączenie zatwierdzonych bloków jest takie samo, jak zatwierdzona treść.

Podczas pracy z blokowymi blokami należy zwrócić szczególną uwagę na obiekty z pustymi listami bloków, ponieważ takie obiekty blokujące mogą, ale nie muszą być puste,!

---

Oryginalny pytanie:

Jeden z naszych bąble przechowywania na rachunku Azure ma pustą listę bloku, mimo że nie jest pusta.

ja pobieranie listy zablokowanych tak (C#):

foreach (var block in _cloudBlob.DownloadBlockList(
    BlockListingFilter.Committed, 
    AccessCondition.GenerateLeaseCondition(_leaseId))) 
{ 
    // ... 
} 

Kod w bloku foreach nie jest wykonywany. Zwrócona lista jest pusta.

Jednak blob donosi, że ma niezerową długość kiedy sprawdzasz: _cloudBlob.Properties.Length

mogę również pobrać blob i zobaczyć, że nie jest pusta.

Czy brakuje mi czegoś? W jaki sposób lista bloków może być pusta, gdy blob nie jest ?! Nie ma znaczenia, czy używam BlockListingFilter.Committed, BlockListingFilter.Uncommitted lub BlockListingFilter.All; lista jest wciąż pusta!

UPDATE

mam skopiowane ten blob do pojemnika publicznym tak, że ten problem może być powielana przez nikogo.

Oto sposób do odtworzenia tego, co jestem w stanie zrozumieć:

właściwości najpierw uzyskać blob od Azure za pomocą interfejsu API REST:

HEAD http://dfdev.blob.core.windows.net/pub/test HTTP/1.1 
Host: dfdev.blob.core.windows.net 

Odpowiedź:

HTTP/1.1 200 OK 
Content-Length: 66 
Content-Type: application/octet-stream 
Last-Modified: Sat, 02 Feb 2013 09:37:19 GMT 
ETag: 0x8CFCF40075A5F31 
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0 
x-ms-request-id: 4b149a7e-2fcd-4ab4-8d53-12ef047cbfa1 
x-ms-version: 2009-09-19 
x-ms-lease-status: unlocked 
x-ms-blob-type: BlockBlob 
Date: Sat, 02 Feb 2013 09:40:54 GMT 

nagłówki odpowiedzi powiedz nam, że jest to blok blob i ma długość 66 bajtów.

Teraz odtworzenia listy bloków od:

http://dfdev.blob.core.windows.net/pub/test?comp=blocklist

ciało Response:

<?xml version="1.0" encoding="utf-8"?><BlockList><CommittedBlocks /></BlockList> 

Tak, blob nie ma żadnych zaangażowanych bloków, nadal ma długość 66 bajtów!

Czy to błąd, czy coś źle zrozumiałem?

Proszę mi pomóc!

UPDATE 2

Znalazłem, że jeśli przesłać blob takiego:

container.GetBlockBlobReference("put-only") 
    .UploadFromStream(File.OpenRead("test-blob")); 

... wtedy jedno żądanie PUT jest wysyłany do Azure i kropelka dostaje pusty lista bloków (tak jak powyżej).

Jednakże, jeśli mogę przesłać blob takiego:

var blob = container.GetBlockBlobReference("put-block"); 
string blockId = Convert.ToBase64String(Guid.NewGuid().ToByteArray()); 
blob.PutBlock(blockId, File.OpenRead("test-blob"), null); 
blob.PutBlockList(new string[] { blockId }); 

... potem dwa wnioski są wysyłane do Azure (jeden na oddanie bloku a drugi za wprowadzenie listy bloku).

Drugi obiekt typu blob pobiera niepustą listę bloków.

Dlaczego pojedynczy PUT nie daje listy bloków?

Czy nie możemy polegać na tym, że łączenie bloków popełnionych przez blob jest równe rzeczywistej zawartości blob ?!

Jeśli nie, w jaki sposób ustalimy, kiedy lista bloków jest właściwa, a kiedy nie jest?

UPDATE 3

I zostały wdrożone obejście dla tego, że moim zdaniem wystarczające, w przypadku, gdy mamy napotkał ten problem. W przypadku, gdy odkryjemy pustą listę bloków ORAZ długość bloba, która jest większa od zera, wtedy zakładamy, że wszystko jest w porządku (choć tak naprawdę nie jest) i kontynuuj przepisywanie danych za pomocą Put Block i Put Block List at następna szansa.

Jednakże, mimo że zrobi to w naszym przypadku, nadal jest bardzo mylące, że niepusty blok blob może zawierać pustą listę zatwierdzonych bloków !!

Czy to jest projektowany element na platformie Azure? Czy ktoś może wyjaśnić, co się dzieje?

UPDATE 4

Microsoft confirmed this issue on the MSDN forums też. Cytat z Allen Chen:

Potwierdziłem w zespole ds. Produktu. To normalne zachowanie. Nagłówek x-ms-blob-content-length jest wielkością zatwierdzonego obiektu typu blob. W twoim przypadku korzystasz z interfejsu API "Put Blob", aby cała zawartość była przesyłana w jednym interfejsie API i została zatwierdzona w tym samym żądaniu.W rezultacie w odpowiedzi Get API List API widzisz, że nagłówek długości treści x-ms-blob ma wartość 66, co oznacza rozmiar zatwierdzonego obiektu typu blob.

Znamy problem, że dokument MSDN API Pobierz listę bloków nie jest do końca jasny na ten temat i będzie nad nim pracował.

Answer 1

Podobnie jak w przypadku testów, wysłanie zapytania o listę bloków blobu przesłanego przy użyciu adresu Put Blob spowoduje zwrócenie pustej listy. Jest to zgodne z projektem.

API UploadFromStream w bibliotece klienta pamięci masowej wykonuje kilka kontroli przed podjęciem decyzji o przesłaniu obiektu blob za pomocą pojedynczej operacji Put Blob lub sekwencji operacji Put Blob, a następnie listy Put Block. Jedną z właściwości, która zmienia to zachowanie, jest SingleBlobUploadThresholdInBytes.