Förstå sökvägslängder i Azure NetApp Files

Fil- och sökvägslängd refererar till antalet Unicode-tecken som tillåts i en filsökväg, inklusive kataloger. I Azure NetApp Files beter sig NFS- och SMB-protokoll något annorlunda i hur de behandlar tecken i fil- och mappnamn.

• I NFS är teckenbytesstorlek en viktig faktor för hur lång en sökväg kan vara.
• I SMB är teckenbytestorlek mindre viktigt, men sökvägslängder kan påverkas av hur klienten konfigureras och hur SMB-resursen är ansluten.

I följande tabell visas de komponent- och sökvägslängder som stöds i Azure NetApp Files-volymer:

Längdöverväganden för NFS-sökväg i Azure NetApp Files

I Azure NetApp Files NFS-volymer är teckenbytestorlek en faktor i de enskilda sökvägslängderna. Till exempel tillåter NFS sökvägskomponenter med en maximal storlek på 255 byte. Filkodningsformatet för American Standard Code for Information Interchange (ASCII) använder 8-bitars kodning, vilket innebär att filsökvägskomponenter (till exempel ett fil- eller mappnamn) i ASCII kan vara upp till 255 tecken eftersom ASCII-tecken är 1 byte stora. Mer information finns i Inverkan på teckenbyte på sökvägslängder.

Längdöverväganden för SMB-sökväg i Azure NetApp Files

SMB-sökvägslängderna i Azure NetApp Files är som standard högst 255 tecken, oavsett bytestorleken för tecknen. Windows-servrar och -klienter stöder sökvägslängder på upp till 260 byte, men de faktiska filsökvägslängderna är kortare på grund av metadata som läggs till i Windows-sökvägar, till exempel <NUL> värde- och domäninformation.

När en sökvägsgräns överskrids i Windows visas en dialogruta:

Till skillnad från NFS lagras större bytestorlekar för tecken i ett separat område av lagringssystemet och alla tecken behandlas som om de är 1 byte stora. Sökvägslängden är dock som standard 255 tecken för hela sökvägen, vilket innebär att varje segment av sökvägen påverkar. Därför kan startpunkten för SMB-resursen påverka det totala antalet tillgängliga tecken för ett fil- eller mappsökvägsnamn. Om till exempel en SMB-servers UNC-sökvägsnamn är \\SMB-SHARE\lägger UNC-namnet till 12 Unicode-tecken i sökvägslängden (inklusive \). Om sökvägen till en specifik fil är \\SMB-SHARE\apps\archive\är det 25 Unicode-tecken av de maximala 255. Endast 3 av 255 tecken används om SMB-resursen mappas till en enhetsbeteckning (till exempel Z:/). Det innebär att en fils eller mapps maximala namnlängd kan vara olika i var och en av ovanstående scenarier.

• \\SMB-SHARE\ (12 tecken) skulle tillåta en mapp eller ett filnamn som är 243 tecken långt
• \\SMB-SHARE\apps\archive\ (25 tecken) skulle tillåta en mapp eller ett filnamn som är 230 tecken långt
• Z:\ (tre tecken, mappat till \\SMB-SHARE\apps\archive\) skulle tillåta en mapp eller ett filnamn som är 252 tecken långt

Medan 255 tecken är den maximala standardsökvägslängden för SMB-resurser (Windows-gräns), stöder Azure NetApp Files också samma större tillåtna sökvägslängder för SMB-resurser som moderna Windows-servrar stöder: upp till 32 767 byte. Beroende på versionen av Windows-klienten kan vissa program dock inte stödja sökvägar som är längre än 260 byte. Enskilda sökvägskomponenter (värdena mellan snedstreck, till exempel fil- eller mappnamn) stöder upp till 255 tecken.

Om ett fil- eller mappnamn överskrider det maximala antalet tecken som tillåts visas följande fel:

# mkdir 256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

mkdir: cannot create directory ‘256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa’: File name too long 

# mkdir 255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

# ls | grep 255 
255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

Utöka SMB-sökvägsgränser i Windows

SMB-sökvägslängder kan utökas när du använder Windows 10/Windows Server 2016 version 1607 eller senare genom att ändra ett registervärde enligt beskrivningen i Begränsning av maximal sökvägslängd. När det här värdet ändras kan sökvägslängderna utökas till upp till 32 767 byte (minus metadatavärden).

När den här funktionen är aktiverad måste du komma åt den SMB-resurs som behöver användas \\?\ i sökvägen för att tillåta längre sökvägslängder. Den här metoden stöder inte UNC-sökvägar, så SMB-delningen måste mappas till en enhetsbokstav.

Användning \\?\Z: ger i stället åtkomst och har stöd för längre filsökvägar.

Lösning om den maximala längden på SMB-sökvägen inte kan ökas

Om den maximala sökvägslängden inte kan aktiveras i Windows-miljön eller om Windows-klientversionerna är för låga finns det en lösning. Du kan montera SMB-resursen djupare i katalogstrukturen och minska sökvägslängden.

I stället för att mappa \\NAS-SHARE\AzureNetAppFiles till Z:, mappa \\NAS-SHARE\AzureNetAppFiles\folder1\folder2\folder3\folder4 till Z:.

NFS-sökvägsgränser

NFS-sökvägsgränser med Azure NetApp Files-volymer har samma gräns på 255 byte för enskilda sökvägskomponenter. Varje komponent utvärderas dock en i taget och kan bearbeta upp till 4 096 byte per begäran med en nästan obegränsad total sökvägslängd. Om varje sökvägskomponent till exempel är 255 byte kan en NFS-klient utvärdera upp till 15 komponenter per begäran (inklusive / tecken). En begäran till en sökväg över gränsen på 4 096 byte ger därför cd felmeddelandet "Filnamnet är för långt".

I de flesta fall är Unicode-tecken 1 byte eller mindre, så gränsen på 4 096 byte motsvarar 4 096 tecken. Om ett tecken är större än 1 byte är sökvägens längd mindre än 4 096 tecken. Tecken med en storlek som är större än 1 byte i storlek räknas mer mot det totala antalet tecken än 1 byte tecken.

Maximal sökvägslängd kan efterfrågas med hjälp av getconf PATH_MAX /NFSmountpoint kommandot .

Kräsna teckenstorlekar

Linux-verktyget uniutils kan användas för att hitta bytestorleken för Unicode-tecken genom att skriva flera instanser av teckeninstansen och visa fältet byte .

Exempel 1: Det latinska versalt A ökar med 1 byte varje gång det används (med ett enda hexvärde på 41, som ligger i intervallet 0–255 ASCII-tecken).

# printf %b 'AAA' | uniname
character  byte  UTF-32   encoded as glyph      name
        0     0  000041   41             A      LATIN CAPITAL LETTER A
        1     1  000041   41             A      LATIN CAPITAL LETTER A
        2     2  000041   41             A      LATIN CAPITAL LETTER A

Resultat 1: Namnet AAA använder 3 byte av 255.

Exempel 2: Det japanska tecknet 字 ökar 3 byte varje instans. Detta kan också beräknas med de tre separata hexkodvärdena (E5, AD, 97) under det kodade som fält. Varje hexvärde representerar 1 byte:

# printf %b '字字字' | uniname
character  byte  UTF-32   encoded as  glyph     name
        0     0  005B57   E5 AD 97       字      CJK character Nelson 1281
        1     3  005B57   E5 AD 97       字      CJK character Nelson 1281
        2     6  005B57   E5 AD 97       字      CJK character Nelson 1281

Resultat 2: En fil med namnet 字字字 använder 9 byte av 255.

Exempel 3: Bokstaven Ä med diaeresis använder 2 byte per instans (C3 + 84).

# printf %b 'ÄÄÄ' | uniname
character  byte  UTF-32   encoded as     glyph  name
        0     0  0000C4   C3 84          Ä      LATIN CAPITAL LETTER A WITH DIAERESIS
        1     2  0000C4   C3 84          Ä      LATIN CAPITAL LETTER A WITH DIAERESIS
        2     4  0000C4   C3 84          Ä      LATIN CAPITAL LETTER A WITH DIAERESIS

Resultat 3: En fil med namnet ÄÄÄ använder 6 byte av 255.

Exempel 4: Ett specialtecken, till exempel emojin 😃 , hamnar i ett odefinierat intervall som överskrider de 0–3 byte som används för Unicode-tecken. Därför använder den ett surrogatpar för sin teckenkodning. I det här fallet använder varje instans av tecknet 4 byte.

# printf %b '😃😃😃' | uniname
character  byte       UTF-32 encoded as  glyph   name
        0     0  01F603   F0 9F 98 83    😃      Character in undefined range
        1     4  01F603   F0 9F 98 83    😃      Character in undefined range
        2     8  01F603   F0 9F 98 83    😃      Character in undefined range 

Resultat 4: En fil med namnet 😃😃😃 använder 12 byte av 255.

De flesta emojis hamnar i intervallet 4 byte men kan gå upp till 7 byte. Av de mer än tusen standard-emojis finns cirka 180 i BMP (Basic Multilingual Plane), vilket innebär att de kan visas som text eller emoji i Azure NetApp Files, beroende på klientens stöd för språktypen.

Mer detaljerad information om BMP och andra Unicode-plan finns i Förstå volymspråk i Azure NetApp Files.

Teckenbytes påverkan på sökvägslängder

Även om en sökvägslängd tros vara antalet tecken i ett fil- eller mappnamn, är det faktiskt storleken på de byte som stöds i sökvägen. Eftersom varje tecken lägger till en bytestorlek till ett namn har olika teckenuppsättningar på olika språk stöd för olika filnamnslängder.

Föreställ dig följande scenarier:

• En fil eller mapp upprepar det latinska alfabettecknet "A" för dess filnamn. (till exempel AAAAAAAAA)

  Eftersom "A" använder 1 byte och 255 byte är sökvägskomponentens storleksgräns tillåts 255 instanser av "A" i ett filnamn.

• En fil eller mapp upprepar det japanska tecknet 字 i dess namn.

  Eftersom "字" har en storlek på 3 byte är filnamnets längdgräns 85 instanser av 字 (3 byte * 85 = 255 byte) eller totalt 85 tecken.

• En fil eller mapp upprepar den flinande ansikts-emojin (😃) i dess namn.

En flinande ansikts-emoji (😃) använder 4 byte, vilket innebär att ett filnamn med endast den emojin skulle tillåta totalt 64 tecken (255 byte/4 byte).

• En fil eller mapp använder en kombination av olika tecken (dvs. Name字😃).

När olika tecken med olika bytestorlekar används i ett fil- eller mappnamn, påverkar varje tecken bytestorleken i fil- eller mapplängden. Ett fil- eller mappnamn för Name字😃 skulle använda 1+1+1+1+3+4 byte (11 byte) av den totala längden på 255 byte.

Särskilda emojibegrepp

Särskilda emojis, till exempel en flagg-emoji, finns under BMP-klassificeringen: emojin återges som text eller bild beroende på klientstöd. När en klient inte stöder bildbeteckningen använder den i stället regionala textbaserade beteckningar.

Till exempel använder flaggan USA tecknen "us" (som liknar de latinska tecknen U+S, men som faktiskt är specialtecken som använder olika kodningar). Uniname visar skillnaderna mellan tecknen.

# printf %b 'US' | uniname
character  byte  UTF-32   encoded as     glyph  name
        0     0  000055   55             U      LATIN CAPITAL LETTER U
        1     1  000053   53             S      LATIN CAPITAL LETTER S


# printf %b '🇺🇸' | uniname
character  byte  UTF-32   encoded as     glyph  name
        0     0  01F1FA   F0 9F 87 BA    🇺      Character in undefined range
        1     4  01F1F8   F0 9F 87 B8    🇸      Character in undefined range

Tecken som är avsedda för flagg-emojis översätts till flaggbilder i system som stöds, men förblir som textvärden i system som inte stöds. Dessa tecken använder 4 byte per tecken för totalt 8 byte när en flagg-emoji används. Därför tillåts totalt 31 flagg-emojis i ett filnamn (255 byte/8 byte).

Specialtecken överväganden

Azure NetApp Files-volymer använder en språktyp av C.UTF-8, som omfattar många länder/regioner och språk, inklusive tyska, kyrilliska, hebreiska och de flesta kinesiska/japanska/koreanska (CJK). De vanligaste texttecken i Unicode är 3 byte eller mindre. Specialtecken – till exempel emojis, musikaliska symboler och matematiska symboler – är ofta större än 3 byte. Vissa använder UTF-16 surrogatparlogik.

Om du använder ett tecken som Azure NetApp Files inte stöder kan du se en varning som begär ett annat filnamn.

I stället för att namnet är för långt beror felet faktiskt på att teckenbytestorleken är för stor för att Azure NetApp Files-volymen ska kunna användas via SMB. Det finns ingen lösning i Azure NetApp Files för den här begränsningen. Mer information om specialteckenhantering i Azure NetApp Files finns i Protokollbeteende med specialteckenuppsättningar.

Överväganden för volymer med dubbla protokoll

När du använder Azure NetApp Files för åtkomst med dubbla protokoll kan skillnaden i hur sökvägslängder hanteras i NFS- och SMB-protokoll skapa inkompatibiliteter mellan filer och mappar. Windows SMB stöder till exempel upp till 32 767 tecken i en sökväg (förutsatt att funktionen för lång sökväg är aktiverad på SMB-klienten), men NFS-stödet kan överskrida den mängden. Om en sökvägslängd skapas i NFS som överskrider stödet för SMB kan klienter därför inte komma åt data när sökvägslängden har nåtts. I dessa fall bör du antingen överväga de nedre gränserna för filsökvägslängder mellan protokoll när du skapar fil- och mappnamn (och mappsökvägsdjup) eller mappar SMB-resurser närmare den önskade mappsökvägen för att minska sökvägens längd.

I stället för att mappa SMB-resursen till den översta nivån på volymen för att navigera ned till en sökväg \\share\folder1\folder2\folder3\folder4till kan du överväga att mappa SMB-resursen till hela sökvägen \\share\folder1\folder2\folder3\folder4till . Därför hamnar en enhetsbeteckningsmappning Z: i önskad mapp och minskar sökvägens längd från Z:\folder1\folder2\folder3\folder4\file till Z:\file.

Next steps

• Förstå volymspråk