Apsara File Storage NAS：讀寫訪問檔案類問題

並發訪問同一檔案時，伺服器端出現無響應35s現象，該如何處理？

原因：當前Linux SMB核心驅動有缺陷，會造成在使用vers=2.1或者3.0掛載時，在某些並發情境不能發出伺服器端期待的SMB BreakAck協議包，導致伺服器端無響應35s。

解決方案一：掛載檔案系統時，使用vers=2.0協議。

解決方案二：執行以下操作。

1. 在載入CIFS模組時，禁用oplocks，執行以下命令。

   # modprobe cifs enable_oplocks=0

2. 當CIFS模組載入完成時，禁用oplocks，執行以下命令。

   # echo 0 > /sys/module/cifs/parameters/enable_oplocks

3. 檢查oplocks的狀態，執行以下命令。

   # cat /sys/module/cifs/parameters/enable_oplocks

   輸出結果中，Y代表啟用（enabled）。N代表禁用（disabled）。

   說明

   • 為了使以上的修改生效，請卸載並重新掛載SMB協議檔案系統。

   • 如果您想使以上的修改永久生效，請建立檔案/etc/modprobe.d/cifs.conf並添加命令列options cifs enable_oplocks=0。

為什麼無法建立符號連結檔案？

問題原因

Linux掛載SMB協議檔案系統時沒有選擇mfsymlinks選項，或者使用了2.0協議版本掛載。

解決方案

Linux掛載SMB協議檔案系統時，使用2.1或3.0協議版本並添加mfsymlinks選項。掛載命令樣本如下，樣本中的參數說明，請參見SMB（Linux）掛載命令參數說明。

sudo mount -t cifs //file-system-id.region.nas.aliyuncs.com/myshare /mnt -o vers=2.1,guest,uid=0,gid=0,dir_mode=0755,file_mode=0755,mfsymlinks,cache=strict,rsize=1048576,wsize=1048576

為什麼SMB協議檔案系統掛載點無響應？

問題原因

在Linux核心為3.10.0-514之前的Linux分發版中，SMB核心驅動在並發情境有時會crash（核心stack如下所示），導致掛載點無法被訪問。核心日誌中有如下類似資訊：

...
[<ffffffffc03c9bc1>] cifs_oplock_break+0x1f1/0x270 [cifs]
[<ffffffff810a881a>] process_one_work+0x17a/0x440
[<ffffffff810a8d74>] rescuer_thread+0x294/0x3c0
...

解決方案

• 使用cache=none重新掛載（效能會受影響）。

• 升級Elastic Compute Service（Linux）的作業系統。

拷貝大檔案時報"cp: error writing '</path/to/file>': Bad file descriptor"，該如何處理？

問題原因

網路或者後端有臨時小故障發生，某些Linux分發版（如Suse）的SMB用戶端功能較弱，不能很好的支援這種故障切換。

解決方案

建議選用NAS SMB推薦的Linux版本，NAS SMB支援的Linux作業系統版本如下表所示：

為什麼寫入檔案系統的中文字元在用戶端顯示為亂碼?

問題現象

在Linux或Windows用戶端向NAS檔案系統寫入的中文字元（檔案名稱、內容等）在另一個平台用戶端顯示為亂碼。

問題原因

Windows用戶端中文編解碼預設使用GBK字元集，Linux用戶端中文編解碼預設使用UTF-8字元集，寫入NAS檔案系統的資料為平台對應字元集編碼後的內容。在另一平台讀取時需要進行解碼，因為兩個平台字元集並不相容，故無法正常解碼，導致顯示內容為不可識別的亂碼。

解決方案

建議您使用Windows用戶端掛載SMB協議NAS檔案系統，Linux用戶端掛載NFS協議檔案系統，從而規避平台不相容問題。

為什麼Windows掛載NFS協議檔案系統建立和開啟檔案時速度緩慢？

問題原因

Windows上使用NFS協議執行個體，會存在大小寫敏感和大小寫不敏感的相容性問題，在目錄裡建立檔案的效能隨著目錄規模增大而明顯下降，原因是每次建立一個檔案都需要對目錄進行遍曆，當目錄規模達到10萬層級時，目錄遍曆一次需要10秒鐘以上。

解決方案

修改掛載參數，增加-o casesensitive=yes欄位，避免目錄遍曆。掛載命令如下所示：

mount -o nolock -o mtype=hard -o timeout=60 -o casesensitive=yes \\file-system-id.region.nas.aliyuncs.com\! Z:

請根據實際情況替換盤符Z和掛載點地址file-system-id.region.nas.aliyuncs.com。

如何解決Windows用戶端對NFS協議檔案系統中的檔案重新命名時返回的invalid device錯誤？

如果NFS協議檔案系統是掛載在檔案系統的子目錄上，當執行檔案重新命名操作時，會返回的invalid device錯誤，請您將檔案系統掛載在檔案系統的根目錄上。具體操作，請參見步驟二：掛載NFS協議的通用型NAS檔案系統。

如何解決在NFS協議檔案系統中建立檔案延遲問題？

• 問題現象：

  ECS-1建立了檔案abc，但是ECS-2需要過一段時間才能看到ECS-1建立的檔案abc，有時會延遲1s，有時甚至會到1分鐘，這是為什嗎？

• 問題原因：

  這是Lookup Cache導致的，符合預期T時間。例如，ECS-2在ECS-1建立檔案abc前進行了訪問，導致ECS-2發生檔案不存在，於是緩衝了一條檔案abc不存在的記錄。在T時間內，由於FileAttr還沒有到期，ECS-2再次訪問時，仍會訪問第一次緩衝到檔案abc不存在的記錄。

• 解決方案：

  如果要保證ECS-1建立檔案後，ECS-2立即就能看到它，可以使用如下方案：

  • 方案一：關閉ECS-2的Negative Lookup Cache，不緩衝不存在的檔案。該方案開銷最小。

    掛載時，添加lookupcache=positive（預設值lookupcache=all）欄位，掛載命令如下所示：

    sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,lookupcache=positive file-system-id.region.nas.aliyuncs.com:/ /mnt

  • 方案二：關閉ECS-2的所有緩衝。該方案會導致效能非常差，請根據業務實際情況選擇合適的方案。

    掛載時，添加actimeo=0欄位，掛載命令如下所示：

    sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,actimeo=0 file-system-id.region.nas.aliyuncs.com:/ /mnt

如何解決向NFS協議檔案系統中寫入資料延遲問題？

• 問題現象：

  ECS-1更新了檔案abc，但是ECS-2立即去讀它，仍然是舊的內容，這是為什嗎？

• 問題原因：

  涉及如下兩個原因。

  • 第一個原因：ECS-1寫了abc後，不會立即flush，會先進行PageCache，依賴應用程式層調用fsync或者close。

  • 第二個原因：ECS-2存在檔案Cache，可能不會立即去服務端取最新的內容。例如，ECS-2在ECS-1更新檔案abc之時，就已經緩衝了資料，當ECS-2再次去讀時，仍然使用了緩衝中的內容。

• 解決方案：

  如果要保證ECS-1建立檔案後，ECS-2立即就能看到它，可以使用如下方案：

  • 方案一：CTO一致性，讓ECS-1或ECS-2的讀寫符合CTO模式，則ECS-2一定能讀到最新資料。具體來說，ECS-1更新檔案後，一定要執行close或者執行fsync。ECS-2讀之前，重新open，然後再去讀。

  • 方案二：關閉ECS-1和ECS-2的所有緩衝。該方案會導致效能非常差，請根據業務實際情況選擇合適的方案。

    • 關閉ECS-1的緩衝。掛載時，添加noac欄位，保證所有寫入立即落盤。掛載命令如下所示：

      sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,noac file-system-id.region.nas.aliyuncs.com:/ /mnt

      說明

      • 如果ECS-1的寫操作完成後會調用fsync，或者使用sync寫，可以將上面的noac替換為actimeo=0，效能會稍好一點。

      • noac等價於actimeo=0加sync（即，強制所有寫入都為sync寫）。

    • 關閉ECS-2的緩衝。掛載時，添加actimeo=0欄位，忽略所有緩衝。掛載命令如下所示：

      sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,actimeo=0 file-system-id.region.nas.aliyuncs.com:/ /mnt

為什麼兩台ECS執行個體在查詢NAS檔案系統中同一檔案時，檔案的屬主不同？

在檔案系統中，標識使用者身份的不是使用者名稱，而是UID或GID，您在ECS執行個體查詢的屬主使用者名稱是由UID資訊轉換得到的，當同一UID在不同ECS執行個體中資訊轉換為不同的使用者名稱，則會被認為是不同的屬主。

例如，在ECS執行個體1中使用admin使用者建立檔案admin_on_machine1，在ECS執行個體2中使用admin使用者建立檔案admin_on_machine2。在ECS執行個體1中執行ll命令，查看已建立的檔案，如下圖所示：在ECS執行個體2中執行ll命令，查看已建立的檔案，如下圖所示：通過兩台ECS執行個體查詢可以看到，同一檔案的屬主使用者名稱不一致。

然後，分別執行id命令，查詢admin使用者資訊。如下圖所示ECS執行個體1中admin使用者的UID為505：如下圖所示ECS執行個體2中admin使用者的UID為2915：如下圖所示執行stat admin_on_machine1 admin_on_machine2命令，查詢到兩個檔案屬於不同的UID：

如何避免多進程或多用戶端並發寫同一記錄檔可能出現的異常？

問題現象

Apsara File Storage NAS為多用戶端提供了統一命名空間的檔案分享權限設定讀寫能力，但在多進程或多用戶端並發寫同一個檔案的情境中（典型的例如並發寫同一個記錄檔），各進程分別維護了獨立的檔案描述符及寫入位置等上下文資訊，而NFS協議本身並沒有提供Atomic Append語義的支援，因此可能會出現寫覆蓋、交叉、串列等異常現象。

解決方案

• （推薦）不同進程或不同用戶端寫入同一檔案系統的不同檔案中，後續分析處理時再進行歸併，這個方案能夠很好地解決並發寫入導致的問題，同時無需使用檔案鎖，不會對效能造成影響。

• 對於並發追加寫同一個檔案（如日誌）的情境，可以使用檔案鎖+seek機制來保證寫入的原子性和一致性。但是檔案鎖+seek是一個比較耗時的操作，可能會對效能產生顯著的影響。下面將對這種方式進行一個簡單的介紹，以供參考。

flock+seek使用方法

由於NFS協議本身沒有提供對Atomic Append語義的支援，因此當並發寫入同一檔案末尾（如日誌）時，很可能會出現相互覆蓋的情況。在Linux中，通過使用flock+seek的方式，可以在NFS協議檔案系統上做到類比Atomic Append，對並發追加寫入同一檔案提供保護和支援。

使用方式如下：

1. 調用fd=open(filename, O_WRONLY | O_APPEND | O_DIRECT) 以追加寫的方式開啟檔案，並且指定 O_DIRECT（直寫，不通過 Page Cache），獲得檔案描述符fd。

2. 調用flock(fd, LOCK_EX|LOCK_NB)嘗試擷取檔案鎖，如果擷取失敗（如鎖已被佔用）則會返回錯誤，此時可以繼續重試或進行錯誤處理。

3. 檔案鎖擷取成功後，調用lseek(fd, 0, SEEK_END)將fd當前的寫入位移定位到檔案末尾。

4. 執行正常的write操作，此時寫入位置應該是檔案的末尾，並且由於有檔案鎖的保護，不會出現並發寫入相互覆蓋的問題。

5. 寫操作執行完成後，調用flock(fd, LOCK_UN)釋放檔案鎖。

使用Linux作業系統在NFS協議檔案系統中執行ls命令時，為什麼會返回523錯誤？

問題現象

Linux用戶端在NFS協議檔案系統中執行ls命令時，返回如下報錯資訊。

原因分析

對檔案系統目錄下執行ls時，該目錄有並發的rename操作，則會返回523錯誤。

解決方案

稍等重試即可。如果還出現類似報錯，請聯絡NAS支援人員進行諮詢。

為什麼SMB協議檔案系統掛載有時候串連不上？

問題現象

當您混用NFS和SMB協議檔案系統，導致第一次通過net use命令掛載NFS協議檔案系統串連失敗後，掛載正確的SMB協議檔案系統也會出現問題。

解決方案

檢查確保掛載正確的檔案系統後，暫時停止掛載，5分鐘後再次掛載。如果還失敗，請聯絡NAS支援人員進行諮詢。

為什麼Administrator能看見掛載的SMB目錄，其他使用者看不到？

該現象是由於Windows的使用者隔離機製造成的。即一個登入使用者的已掛載目錄在另一個使用者的登入介面中不會顯示。

要實現多使用者的共用，需要建立一個目錄連結。比如C盤下建立一個myshare，命令如下：

mklink /D C:\myshare \\xxxxxxx-xxxx.cn-beijing.nas.aliyuncs.com\myshare\

如何解決Linux掛載SMB協議檔案系統效能不佳？

如果SMB協議檔案系統效能不佳，您可以從以下方面進行排查。

• 原因1：SMB單個檔案系統的吞吐能力與儲存量是相聯絡的。單檔案系統的吞吐（讀+寫）上限與當前儲存量呈線性關係。

  解決方案：使用fio工具來測試SMB協議檔案系統效能。具體操作，請參見NAS效能測試。

• 原因2：Elastic Compute Service（Linux）的單機網路頻寬較小。

  解決方案：使用多個Elastic Compute Service（Linux）達到檔案系統的總體預期效能。

• 原因3：禁用了SMB協議檔案系統的用戶端緩衝。

  解決方案：在掛載SMB協議檔案系統時，cache=none表示禁用緩衝，預設或者cache=strict表示使用緩衝；您可以通過sudo mount | grep cifs命令檢查所用的選項是否正確。

• 原因4：沒有設定合適的SMB用戶端的I/O大小。

  解決方案：根據業務需求調整rsize及wsize，預設值：1048576。

• 原因5：Elastic Compute Service（Linux）的CPU或記憶體的規格過低，或被其它業務佔用過多。

  解決方案：選擇合適的Elastic Compute Service（Linux）規格、檢查系統其它應用資源，確保系統滿足CPU和記憶體要求。您可以通過top命令檢查系統CPU、MEM使用方式。

• 原因6：掛載時使用了atime選項。

  解決方案：如果您的業務不是對檔案的訪問時間（atime）極為敏感，請不要在掛載時使用atime選項。

• 原因7：遇到大量小檔案頻繁讀、少量寫但需要寫時通知的WebServer情境。

  解決方案：您可以在用戶端配置該WebServer（如Apache）產品特定的緩衝機制或者聯絡阿里雲NAS團隊開通WebServer情境加速功能。

Linux訪問SMB協議檔案系統時，報Permission denied錯誤，該怎麼解決？

原因：Linux管理員在掛載時使用了不正確的UID、GID、file_mode、dir_mode。

解決方案：檢查是否正確設定了UID、GID、file_mode、dir_mode等掛載選項。更多資訊，請參見掛載SMB協議檔案系統。

如何變更SMB協議檔案系統中檔案名稱大小寫？

SMB協議檔案系統對檔案名稱大小寫不敏感，和Windows系統保持一致。但在檔案名稱大小寫改名這個情境暫時沒有支援。

您可以先從大寫檔案名稱改成一個其它名字的檔案，再改成小寫檔案名稱，反之亦然。

為什麼不能改變檔案owner，檔案和目錄mode？

現在暫時不支援動態改變，只能在掛載時指定。更多資訊，請參見掛載SMB協議檔案系統。

尾碼為.nfs的檔案是怎麼產生的？如何刪除？

在應用程式已經開啟某檔案時，如果刪除該檔案，則會產生尾碼為.nfs的臨時檔案。當訪問進程關閉後，該臨時檔案將自動被刪除。

訪問NAS檔案系統目錄下的檔案時，返回bind conn to session failed on NFSv4 server該如何解決？

• 問題原因

  由於Apsara File Storage NAS不支援NFSv4.1協議，當您使用NFSv4.1協議掛載檔案系統時產生該報錯。

• 解決方案

  請您根據業務情境選擇使用NFSv3或NFSv4.0協議重新掛載檔案系統。更多資訊，請參見掛載檔案系統情境說明。

如何處理多個ECS執行個體掛載同一NFS協議檔案系統出現資料不同步的情況？

問題現象

NAS在多掛載點的情況下，不同用戶端進行即時同步時存在較長時間延遲的問題。

問題原因

作業系統kernel預設對檔案和目錄的屬性進行維護，將其產生一份metadata緩衝，以減少NFSPROC_GETATTR遠端程序呼叫的需求。

解決方案

執行以下掛載命令，禁用檔案和目錄屬性的緩衝。

mount -t nfs4 -o noac file-system-id.region.nas.aliyuncs.com:/ /mnt

其中，file-system-id.region.nas.aliyuncs.com為檔案系統掛載點地址，請根據實際值替換；/mnt ：當前伺服器上待掛載的本地路徑，請根據實際情況替換路徑。

為什麼卸載舊NAS並重新掛載新NAS後，容器Pod仍將資料寫入舊NAS？

問題原因

將NAS掛載到ECS並通過本機存放區卷（HostPath）映射的方式將NAS的掛載目錄映射到容器時，容器中的掛載資訊獨立於ECS，ECS後續對NAS掛載目錄進行卸載或者掛載新NAS時，已經啟動的容器仍然會使用其啟動時掛載的舊NAS。

解決方案

在ECS上重新掛載新NAS後，重啟容器Pod。

伺服器重啟或停機後，為什麼NAS裡的檔案看不到了？

如果檔案系統仍存在，此原因一般是伺服器未配置自動掛載NAS。

如何手動再次掛載NAS請參考掛載檔案系統情境說明。

如需實現重啟後NAS自動掛載功能，請參考以下文檔：

• Linux系統自動掛載NFS協議檔案系統

• Windows系統自動掛載SMB協議檔案系統

為什麼Linux掛載SMB協議檔案系統遷移和複製檔案時速度緩慢？

如果已經排除了檔案系統本身的效能問題，則可能原因是您沒有使用並髮式遷移或複製檔案。您可以通過以下開源工具進行遷移或複製。

• GNU Parallel

  根據系統資源，選擇合適的線程數。樣本：find * -type f | parallel --will-cite -j 10 cp {} /mnt/smb/ &

• Fpart

• Fpsync

• multi

為什麼向檔案系統寫入資料時，返回Disk quota exceeded錯誤資訊？

• 問題原因

  目標目錄的使用量或檔案數超過了設定的使用者配額限制，因此導致寫入操作（包括增加檔案長度、建立檔案、目錄、移動檔案到目錄等操作）失敗，返回類似Disk quota exceeded的錯誤資訊。

• 解決方案

  1. 建議您儘快清理資料釋放空間，或者提升該目錄的容量限制。具體操作，請參見編輯單條使用者配額。

  2. 清理完成後，建議先對配額的目錄執行測試性的寫操作（例如，建立並寫資料到測試檔案）來觸發配額緩衝的非同步重新整理，判斷這些測試性寫操作能夠成功，然後再重新啟動業務。

如何解決訪問NFS協議檔案系統時，返回無存取權限問題？

您可參照以下操作步驟為系統配置AnonymousGID和AnonymousUID。

1. 登入掛載檔案系統的ECS伺服器。

2. 開啟命令提示字元，執行regedit命令，進入登錄編輯程式頁面。

3. 選擇HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > ClientForNFS > CurrentVersion > Default。

4. 右擊空白處，選擇建立 > DWORD（32位）值，並建立以下兩個登錄機碼。

   • AnonymousGID，值為0。

   • AnonymousUID，值為0。

5. 重啟ECS執行個體。

6. 重新掛載NFS協議的通用型NAS檔案系統。

   mount -o nolock -o mtype=hard -o timeout=60 \\file-system-id.region.nas.aliyuncs.com\! Z:

   請根據實際情況替換盤符Z:和掛載點網域名稱file-system-id.region.nas.aliyuncs.com。

7. 執行mount檢查是否掛載成功。

   掛載完成後，回顯資訊必須包括mount=hard、locking=no以及timeout參數>=10，否則說明掛載有問題。

   

能否通過執行chown修改NAS根目錄許可權？

當前不允許使用者修改NAS根目錄許可權。

如果您希望控制本地掛載的NAS目錄的許可權，可以考慮使用子目錄掛載的方式。例如，如果將NAS根目錄掛載到本地的/data目錄，將無法通過chown修改/data目錄的屬主和屬組。如果將NAS子目錄（需提前建立）掛載到本地的/data目錄，即可以通過chown修改/data目錄的屬主和屬組。需要注意的是，在NAS中建立子目錄時，仍需要先掛載NAS根目錄後建立。關於如何建立子目錄並完成掛載，請參見如何在Linux系統中建立NAS子目錄並完成掛載？。