Hantera fillås

  • Artikel

Azure Files ger åtkomst till molnfilresurser via följande protokoll:

  • Server Message Block (SMB)
  • Network File System (NFS)
  • FileREST (HTTPS)

Det här avsnittet beskriver hur du hanterar fillåsningsinteraktioner mellan SMB och FileREST. NFS-filresurser har olika låssemantik och stöder en delmängd av FileREST-API:erna. Det här avsnittet gäller inte för NFS-filresurser.

SMB-fillåsning

SMB-klienter som monterar filresurser kan använda låsningsmekanismer för filsystem för att hantera åtkomst till delade filer. Dessa omfattar:

  • Hela filåtkomstdelning för läsning, skrivning och borttagning.
  • Byteintervall låser för att hantera läs- och skrivåtkomst till regioner i en enda fil.

När en SMB-klient öppnar en fil anger den både filåtkomst och resursläge. Följande alternativ för filåtkomst används vanligtvis av SMB-klienter, även om alla kombinationer tillåts:

  • Ingen: Öppnar en fil för endast åtkomst till frågeattribut.
  • Läsa: Öppnar en fil för skrivskyddad åtkomst.
  • Skriva: Öppnar en fil för skrivåtkomst.
  • Läs/skriv: Öppnar en fil med läs-/skrivbehörigheter.
  • Ta bort: Öppnar en fil för endast borttagningsåtkomst.

Följande filresurslägen används vanligtvis av SMB-klienter:

  • Ingen: Nekar delning av den aktuella filen. Alla förfrågningar om att öppna filen med läs-, skriv- eller borttagningsåtkomst misslyckas tills filen har stängts.
  • Delad läsning: Tillåter efterföljande öppning av filen för läsning. Om den här flaggan inte har angetts misslyckas alla förfrågningar om att öppna filen för läsning tills filen stängs.
  • Delad skrivning: Tillåter att filen öppnas senare för skrivning. Om den här flaggan inte har angetts misslyckas alla förfrågningar om att öppna filen för skrivning tills filen stängs.
  • Delad läsning/skrivning: Tillåter efterföljande öppning av filen för läsning eller skrivning. Om den här flaggan inte har angetts misslyckas alla förfrågningar om att öppna filen för läsning eller skrivning tills filen stängs.
  • Delad borttagning: Tillåter efterföljande borttagning av en fil. Om den här flaggan inte har angetts misslyckas alla begäranden om att ta bort filen tills filen har stängts.

Exempel på öppna SMB-klientfiler

Tänk dig följande öppna filexempel:

  • Filen öppnas utan delningsfel

    • Klient A öppnar filen med FileAccess.Read och FileShare.Write (nekar efterföljande läsning/borttagning när den är öppen).
    • Klient B öppnar sedan filen med FileAccess.Write fileshare.read (nekar efterföljande skrivning/borttagning när den är öppen).
    • Resultatet: Detta är tillåtet eftersom det inte finns någon konflikt mellan filåtkomst och filresurslägen.

  • Delningsfel på grund av filåtkomst

    • Klient A öppnar filen med FileAccess.Write och FileShare.Read (nekar efterföljande skrivning/borttagning när den är öppen).
    • Klient B öppnar sedan filen med FileAccess.Write fileshare.write (nekar efterföljande läsning/borttagning när den är öppen).
    • Resultatet: Klient B stöter på en delningsöverträdelse. Klienten angav en filåtkomst som nekas av delningsläget som tidigare angavs av klient A.

  • Delningsfel på grund av delningsläge

    • Klient A öppnar filen med FileAccess.Write och FileShare.Write (nekar efterföljande läsning/borttagning när den är öppen).
    • Klient B öppnar sedan filen med FileAccess.Write fileshare.read (nekar efterföljande skrivning/borttagning när den är öppen).
    • Resultatet: Klient B stöter på en delningsöverträdelse. Klienten angav ett resursläge som nekar skrivåtkomst till en fil som fortfarande är öppen för skrivåtkomst.

Fil-REST-filåtkomst

När du utför en FileREST-åtgärd måste den här åtgärden respektera det delningsläge som anges för alla filer som öppnas på en SMB-klient. Använd följande filåtkomstläge för att avgöra om åtgärden kan slutföras:

FileREST-åtgärd Filåtkomstmotsvarighet
Lista kataloger och filer Ej tillämpligt.
Skapa fil Skriv, ta bort.
Hämta fil Läsa.
Ange filegenskaper Skriva.
Hämta filegenskaper Ej tillämpligt.
Ange filmetadata Skriva.
Hämta filmetadata Ej tillämpligt.
Ta bort fil Ta bort.
Placera intervall Skriva.
Listintervall Läsa.
Lånefil Skriv, ta bort och delad läsning under lånets varaktighet.

Listkataloger och filer, Hämta filegenskaper och Hämta filmetadata fungerar inte på filinnehåll. De här åtgärderna kräver inte läsåtkomst till filen (det vill sägs att dessa åtgärder lyckas även om en SMB-klient har filen öppen för exklusiv läsåtkomst).

Följande är exempel på FileREST-begäranden som interagerar med SMB-resurslägena:

  • FileREST Hämta fildelningsfel

    • SMB-klienten öppnar filen med FileAccess.Read och FileShare.Write (nekar efterföljande läsning/borttagning när den är öppen).
    • REST-klienten utför sedan en Get File-åtgärd på filen (därmed med hjälp av FileAccess.Read som anges i föregående tabell).
    • Resultatet: REST-klientens begäran misslyckas med statuskoden 409 (konflikt) och felkoden SharingViolation. SMB-klienten har fortfarande filen öppen och nekar läs-/borttagningsåtkomst.

  • FilREST– Delningsfel för put-range

    • SMB-klienten öppnar filen med FileAccess.Write och FileShare.Read (nekar efterföljande skrivning/borttagning när den är öppen).
    • REST-klienten utför sedan en Put Range-åtgärd på filen (och använder FileAccess.Write därmed enligt ovanstående tabell).
    • Resultatet: REST-klientens begäran misslyckas med statuskoden 409 (konflikt) och felkoden SharingViolation. SMB-klienten har fortfarande filen öppen och nekar skriv-/borttagningsåtkomst.

Nästa avsnitt innehåller en omfattande tabell med scenarier med delningsöverträdelser för FileREST API.

Konsekvenser för SMB-klientdelningsläge på FileREST

Beroende på vilket resursläge du anger när en SMB-klient öppnar en fil är det möjligt för FileREST att returnera statuskod 409 (konflikt) med felkoden SharingViolation. I följande tabell visas ett antal scenarier.

SMB-klientfildelningsläge FileREST-åtgärder misslyckas med en delningsöverträdelse
None

(Deny Read, Write, Delete)		 Följande läs-, skriv-, låne- och borttagningsåtgärder i filen misslyckas:

  • Skapa fil
  • Hämta fil
  • Ange filegenskaper
  • Ange filmetadata
  • Ta bort fil
  • Placera intervall
  • Listintervall
  • Lånefil
Shared Read

Deny Write, Delete)		 Följande skriv-, låne- och borttagningsåtgärder för filen misslyckas:

  • Skapa fil
  • Ange filegenskaper
  • Ange filmetadata
  • Ta bort fil
  • Placera intervall
  • Lånefil
Shared Write

(Deny Read, Delete)		 Följande läs-, låne- och borttagningsåtgärder för filen misslyckas:

  • Skapa fil
  • Hämta fil
  • Ta bort fil
  • Listintervall
  • Lånefil
Shared Delete

(Deny Read, Write)		 Följande läs-, skriv- och låneåtgärder för filen misslyckas:

  • Skapa fil
  • Hämta fil
  • Ange filegenskaper
  • Ange filmetadata
  • Placera intervall
  • Listintervall
  • Ta bort fil
  • Lånefil
Shared Read/Write

(Deny Delete)		 Följande låne- och borttagningsåtgärder för filen misslyckas:

  • Skapa fil
  • Ta bort fil
  • Lånefil
Shared Read/Delete

(Deny Write)		 Följande skriv-, låne- och borttagningsåtgärder för filen misslyckas:

  • Skapa fil
  • Ange filegenskaper
  • Ange filmetadata
  • Placera intervall
  • Ta bort fil
  • Lånefil
Shared Write/Delete

(Deny Read)		 Följande läs- och låneåtgärder för filen misslyckas:

  • Hämta fil
  • Listintervall
  • Ta bort fil
  • Lånefil
Shared Read/Write/Delete

(Deny Nothing)		 Ta bort fil

Azure Files returnerar endast delningsöverträdelser när filer är öppna på SMB-klienter. För att en FileREST Delete File-åtgärd ska lyckas kan det inte finnas några SMB-klienter med referenser öppna mot den filen. Mer information finns i Ta bort filåtgärd och Interaktion mellan fileREST- och SMB-opportunistiska lås.

Konsekvenser för SMB-fillåsning på FileREST Lease File API

Beroende på vilka alternativ för filåtkomst du anger när en SMB-klient öppnar en fil är det möjligt för FileREST Lease File API att returnera statuskod 409 (konflikt), med felkoden SharingViolation. Följande tabell innehåller ytterligare information:

Åtkomstalternativ för SMB-klientfiler Skaffa lån på fil utan aktivt lån med LEASE File API
Ingen Lyckas
Läsa Lyckas
Skriva Misslyckas på grund av SharingViolation
Ta bort Misslyckas på grund av SharingViolation
Läsa|Skriva Misslyckas på grund av SharingViolation
Läsa|Ta bort Misslyckas på grund av SharingViolation
Skriva |Ta bort Misslyckas på grund av SharingViolation
Läsa|Skriva |Ta bort Misslyckas på grund av SharingViolation

Azure Files returnerar endast delningsöverträdelser när filer är öppna på SMB-klienter. Observera att för att en FileREST Lease File-åtgärd ska lyckas kan det inte finnas några SMB-klienter med skrivnings- eller borttagningshandtag öppna mot den filen. Mer information finns i Lease File-åtgärden och Interaktion mellan FileREST och SMB opportunistiska lås.

Fil-REST Lease File implications for SMB file locking

Ett lån på en fil ger exklusiv skriv- och borttagningsåtkomst till filen. När en SMB-klient öppnar en fil måste den respektera låset för alla filer som hyrs av fileREST-lånefilen. Du kan använda följande tabell för att avgöra om SMB-åtgärden för öppna filer kan slutföras:

FileREST-fillåntillstånd SMB-åtgärder misslyckas med en delningsöverträdelse
Leasade SMB-klienter som öppnar filen med följande filåtkomst misslyckas:

  • FileAccess.Write
  • FileAccess.Delete
  • FileAccess.Read|FileAccess.Write
  • FileAccess.Write|FileAccess.Delete
  • FileAccess.Read|FileAccess.Write|FileAccess.Delete
Tillgängligt Ingen
Bruten Ingen

Konsekvenser för SMB-borttagning på FileREST

När en SMB-klient öppnar en fil för borttagning markeras filen som väntande borttagning tills alla andra SMB-klient öppna referenser på filen stängs. När en fil markeras som väntande borttagning returnerar alla FileREST-åtgärder på filen statuskoden 409 (konflikt), med felkoden SMBDeletePending. Statuskod 404 (hittades inte) returneras inte eftersom det är möjligt för SMB-klienten att ta bort flaggan för väntande borttagning innan filen stängs. Med andra ord förväntas statuskod 404 (hittades inte) endast när filen har tagits bort.

När en fil är i ett SMB-väntande borttagningstillstånd tas den List Files inte med i resultatet.

Observera också att FileREST Delete File och Delete Directory åtgärderna utförs atomiskt och inte resulterar i väntande borttagningstillstånd.

Filattributkonsekvenser på FileREST

Det är möjligt för SMB-klienter att läsa och ange filattribut, inklusive:

  • Arkiv
  • Skrivskyddad
  • Dold
  • System

Om en fil eller katalog är markerad som skrivskyddad misslyckas alla FileREST-åtgärder som försöker skriva till filen med statuskoden 412 (Villkorsfel) och felkoden ReadOnlyAttribute. Dessa åtgärder omfattar följande:

  • Create File
  • Set File Properties
  • Set File Metadata
  • Put Range

Dessa filattribut kan inte anges eller läsas från REST-klienter. När en fil har gjorts skrivskyddad kan REST-klienter inte skriva till filen förrän SMB-klienten tar bort det skrivskyddade attributet.

Interaktion mellan FileREST- och SMB-opportunistiska lås

SMB opportunistiskt lås (oplock) är en cachelagringsmekanism som SMB-klienter begär för att förbättra prestanda och minska nätverksöverföringar. En SMB-klient kan cachelagrat det senaste tillståndet för en viss fil eller katalog. Det finns flera opportunistiska låstyper som kallas SMB-lånetyper:

  • Läs (R): SMB-klienten kan läsa från lokal cache.
  • Skriv (W): SMB-klienten kan skriva lokalt, utan att behöva tömma data tillbaka till Azure-filresursen.
  • Handtag (H): SMB-klienten krävs inte för att omedelbart meddela Azure-filresursen när ett handtag stängs. Den här låstypen är användbar när ett program fortsätter att öppna och stänga filer med samma åtkomst- och delningsläge.

Dessa lånetyper är oberoende av det angivna åtkomst- och delningsläget. Vanligtvis försöker en SMB-klient hämta alla lånetyper när den öppnar ett nytt handtag mot en fil, oavsett åtkomst- och delningsläge.

Beroende på vilken FileREST-åtgärd som anropas kan du behöva begära att bryta ett befintligt opportunistiskt lås. Vid skrivåtgärder måste SMB-klienten tömma cachelagrade ändringar i Azure-filresursen. Här är några fall där varje typ av oplock måste brytas:

  • Ett Läs-oplock (R) måste brytas när en skrivåtgärd utfärdas, till exempel Put Range.

  • En skrivåtgärd (W) måste brytas när en läsåtgärd utfärdas, till exempel Get File.

  • Ett handtag (H) måste brytas när en klient utfärdar en borttagningsåtgärd. Azure Files kräver att inga referenser kan vara öppna om en borttagningsåtgärd ska lyckas.

    Handtags oplocks bryts också när en FileREST-åtgärd står inför en delningsöverträdelse med ett befintligt SMB-handtag. Detta inträffar för att kontrollera att handtagen fortfarande öppnas av ett program som körs på klienterna.

Att bryta oplocken kan kräva tömning av cachelagrade SMB-klientändringar, vilket kan orsaka fördröjningar i åtgärdssvarstiden. Tömning kan också orsaka att åtgärden misslyckas med statuskoden 408 (tidsgräns för begäran) och felkoden ClientCacheFlushDelay.

I följande avsnitt beskrivs scenarier där oplocks bryts.

En oplock-paus och SMB-klientspolning krävs och REST-klienten får en fördröjning

Se följande exempel:

  1. SMB-klienten öppnar en fil, hämtar ett RWH-oplock och skriver data lokalt.

  2. REST-klienten skickar en Get File begäran.

    • Azure-filresursen bryter skrivåtgärderna (W) och lämnar klienten med en RH-oplock.
    • SMB-klienten rensar sina cachelagrade data mot Azure-filresursen och bekräftar oplock-pausen.
    • Azure-filresursen Get File bearbetar begäran och svarar tillbaka med begärda data.

I det här exemplet uppstår fördröjningar för REST-klienten. Den här situationen orsakas av oplock-pausen och den tid det tar för SMB-klienten att tömma sina data mot Azure-filresursen.

Efterföljande anrop för att Get File inte uppleva några ytterligare fördröjningar, eftersom skriv-oplocken (W) redan har brutits.

En oplock-paus krävs, men REST-klienten får ingen fördröjning

Se följande exempel:

  1. SMB-klienten har skaffat en RH-oplock.

  2. REST-klienten skickar en Put Range begäran.

    • Azure-filresursen skickar en oplock break-begäran till SMB-klienten och väntar inte på något svar.
    • Azure-filresursen Put Range bearbetar begäran.

I det här exemplet krävs oplock-pausen Put Range , men begäran får inga ytterligare fördröjningar. Ett svar behövs inte när läs-oplocken bryts.

Azure Files beteende

I följande tabell sammanfattas beteendet för Azure Files för varje FileREST-åtgärd. Det här beteendet baseras på oplock-tillståndet för den SMB-klient som redan har fått ett handtag på samma fil. Dessutom förutsätter beteendet att SMB hanterar åtkomst och delning inte står i konflikt med FileREST-åtgärden.

Om det finns en konflikt bryts även handtagets oplock för att säkerställa att handtaget fortfarande är öppet på klienten. Vid en blockerande oplock-paus måste Azure Files vänta på en bekräftelse på att pausen lyckades. Om oplocken inte blockeras behöver Azure Files inte vänta.

FileREST-åtgärd Aktuella oplocktyper Olåst avbrott utfört Resulterande oplock
Hämta fil RWH Ja (blockering) RH
Hämta fil RH No RH
Hämta fil RW Ja (blockering) R
Hämta filegenskaper RWH Ja (blockering) RH
Hämta filegenskaper RH No RH
Hämta filegenskaper RW Ja (blockering) R
Listintervall RWH Ja (blockering) RH
Listintervall RH No RH
Listintervall RW Ja (blockering) R
Hämta filmetadata RWH Ja (blockering) RH
Hämta filmetadata RH No RH
Hämta filmetadata RW Ja (blockerande) R
Lista filer RWH No RWH
Lista filer RH No RH
Lista filer RW No RW
Placera intervall RWH Ja (blockerande) Ingen
Placera intervall RH Ja (icke-blockerande) Ingen
Placera intervall RW Ja (blockerande) Ingen
Ange filegenskaper RWH Ja (blockerande) Ingen
Ange filegenskaper RH Ja (icke-blockerande) Ingen
Ange filegenskaper RW Ja (blockerande) Ingen
Ange filmetadata RWH Ja (blockerande) Ingen
Ange filmetadata RH Ja (icke-blockerande) Ingen
Ange filmetadata RW Ja (blockerande) Ingen
Ta bort fil RWH Ja (blockerande) RW
Ta bort fil RH Ja (blockerande) R
Ta bort fil RW No RW

Om en blockerande oplockbrytning krävs misslyckas FileREST-åtgärden under vissa förhållanden. Om pausen inte lyckas inom den angivna tidsgränsen för begäran eller inom 30 sekunder, beroende på vilket som slutförs först, returnerar tjänsten statuskoden 408 (tidsgräns för begäran) och felkoden ClientCacheFlushDelay.

Begäran Delete File kräver också att oplock-referensen (H) bryts. Om du bryter handtaget ser du till att det inte finns några filreferenser som fortfarande öppnas av ett SMB-klientprogram när en REST-klient anropar Delete File. Om det finns en delningsöverträdelse misslyckas begäran med statuskoden 409 (konflikt) och felkoden SharingViolation.

Se även

Azure Files begrepp