閱讀前言

本文以QNX系統(tǒng)官方的文檔英文原版資料為參考，翻譯和逐句校對后，對QNX操作系統(tǒng)的相關(guān)概念進(jìn)行了深度整理，旨在幫助想要了解QNX的讀者及開發(fā)者可以快速閱讀，而不必查看晦澀難懂的英文原文，這些文章將會(huì)作為一個(gè)或多個(gè)系列進(jìn)行發(fā)布，從遵從原文的翻譯，到針對某些重要概念的穿插引入，以及再到各個(gè)重要專題的梳理，大致分為這三個(gè)層次部分，分不同的文章進(jìn)行發(fā)布，依據(jù)這樣的原則進(jìn)行組織，讀者可以更好的查找和理解。

---

1. 文件系統(tǒng)

本文接上一篇繼續(xù)介紹文件系統(tǒng)：《?2-2-18-9 QNX系統(tǒng)架構(gòu)之文件系統(tǒng)（二）》

1.7. DOS文件系統(tǒng)

DOS文件系統(tǒng)fs-dos.so提供了對DOS磁盤的透明訪問，因此你可以像對待POSIX文件系統(tǒng)一樣對待DOS文件系統(tǒng)。這種透明性允許進(jìn)程在沒有任何特殊知識或工作的情況下對DOS文件進(jìn)行操作。

磁盤上的DOS文件系統(tǒng)結(jié)構(gòu)老舊且效率低下，并且缺乏許多理想的特性。僅有的主要優(yōu)點(diǎn)是它在 DOS 和 Windows 環(huán)境中具有可移植性。只有在需要將DOS文件傳輸?shù)叫枰钠渌麢C(jī)器時(shí)，才應(yīng)該選擇這個(gè)DOS文件系統(tǒng)。如果不存在 DOS文件可移植性問題，那么請考慮單獨(dú)使用 Power-Safe 文件系統(tǒng)；如果存在 DOS 文件可移植性問題，則再考慮與 DOS 文件系統(tǒng)結(jié)合使用。

如果沒有對應(yīng)于 POSIX 特性的 DOS，fs-dos.so，要么返回錯(cuò)誤，要么返回合理的默認(rèn)值。例如，嘗試創(chuàng)建 link() 將導(dǎo)致返回適當(dāng)?shù)?code>errno。另一方面，如果試圖讀取文件上的 POSIX 時(shí)間，fs-dos.so將會(huì)把對任何不支持的“時(shí)間”的讀取當(dāng)作是對最后一次的寫入時(shí)間的讀取。

• DOS version support【DOS 版本支持】

fs-dos.so程序，支持從 DOS 2.1 版本 到 帶有長文件名的 Windows 98 的硬盤分區(qū)。

• DOS text files【DOS 文本文件】

DOS 用兩個(gè)字符 （CR/LF）結(jié)束文本文件中的每行，而POSIX（和大多數(shù)其他）系統(tǒng)以單個(gè)字符（LF）結(jié)束每行。 請注意，在讀取時(shí)，fs-dos.so不會(huì)嘗試轉(zhuǎn)換文本文件。但是大多數(shù)實(shí)用程序和軟件程序可以不受這種差異的影響。

另外，請注意，一些非常舊的 DOS 程序可能會(huì)使用 Ctrl–Z （^Z） 作為文件的結(jié)束符。對該字符同樣不會(huì)進(jìn)行修改。

@>> 閱讀擴(kuò)展：

這里的^Z并不是一個(gè)通過常規(guī)鍵值表示的組合，?而是一個(gè)特殊的控制字符。?在ASCII碼表中，?Ctrl–Z對應(yīng)的字符編碼值是26，?也就是ASCII碼的控制字符END OF FILE（?EOF）?。這個(gè)字符在文本文件中用來表示文件的結(jié)束，?特別是在一些舊的文本編輯器和DOS程序中。?

• QNX-to-DOS filename mapping

在 DOS 中，文件名不能包含如下任何字符：

/ \ [ ] : * | + = ; , ?

嘗試創(chuàng)建包含這些無效字符之一的文件將返回錯(cuò)誤。DOS（8.3 格式） 還期望所有字母字符都是大寫的，因此當(dāng)在磁盤上創(chuàng)建文件名時(shí)，fs-dos.so會(huì)映射這些字符為大寫。但是，在返回文件名給 QNX Neutrino 應(yīng)用程序時(shí)，默認(rèn)情況下它會(huì)把文件名映射為小寫，以便 QNX Neutrino 用戶和程序始終可以看到并鍵入小寫（通過sfn= sfn_mode選項(xiàng)）

• Handling filenames【處理文件名】

你可以指定期望fs-dos.so的處理方式長文件名（通過lfn= lfn_mode選項(xiàng)）。

• • 忽略它們 - 僅顯示/創(chuàng)建 8.3 格式的文件名。
  • 顯示它們 - 如果文件名長度超過 8.3 格式規(guī)定的長度或使用了大小寫混合。
  • 始終創(chuàng)建短文件名和長文件名。

如果使用ignore選項(xiàng)，則可以指定 是否以靜默方式截?cái)喑?8.3 格式所限制部分的文件名字符。

• International filenames【國際化文件名】

DOS 文件系統(tǒng)支持 DOS“code page【代碼頁】”（國際字符集）用于區(qū)域化文件名。 短的 8.3 格式文件名使用特定字符集存儲(chǔ)（通常區(qū)域化最常見的擴(kuò)展字符，以第 8 比特位字符范圍進(jìn)行編碼）。 所有常見的美國以及西歐和東歐的code page【代碼頁】，支持 （437、850、852、866、1250、1251、1252）。 如果你制作的軟件必須訪問各種 DOS/Windows 硬盤，或在非美國英語國家/地區(qū)運(yùn)行，則該功能提供了重要的可移植性，文件名將會(huì)同時(shí)使用 Unicode 編碼及區(qū)域化名稱進(jìn)行創(chuàng)建，并且是可通過任意一個(gè)名稱進(jìn)行訪問。

DOS 文件系統(tǒng)僅支持文件名國際化文本。 不會(huì)嘗試了解數(shù)據(jù)內(nèi)容，使用 Windows "shortcut【快捷方式】"（.LNK） 文件，該文件將會(huì)被解析并 translated to symbolic links（如果你指定了（lnk=lnk_mode）選項(xiàng)。

• DOS volume labels【卷標(biāo)】

DOS文件系統(tǒng)使用卷標(biāo)的概念，它實(shí)際是一個(gè)的 directory 項(xiàng)。 為了區(qū)分卷標(biāo)和實(shí)際的 DOS 目錄，程序fs-dos.so根據(jù)你指定卷標(biāo)選項(xiàng)的方式報(bào)告卷標(biāo)。你可以選擇：

• • 忽略卷標(biāo)。
  • 將卷標(biāo)簽顯示為名稱專用文件。
  • 將卷標(biāo)顯示為帶有等號的名稱專用文件（=） 作為卷名稱的第一個(gè)字符（默認(rèn)值）。

• DOS-QNX permission mapping【權(quán)限映射】

DOS 并非支持所有的 POSIX 所指定的權(quán)限位。 例如，它用 READ_ONLY 位代替了單獨(dú)的 READ 和 WRITE 位；它沒有 EXECUTE 位。 創(chuàng)建 DOS 文件時(shí)，如果所有 POSIX WRITE 位都被關(guān)閉，那么 READ_ONLY 會(huì)被置位。訪問 DOS 文件時(shí)，對于 user、group 和 other，始終假定 POSIX READ 位被置位。

由于你無法執(zhí)行沒有 EXECUTE 權(quán)限的文件，fs-dos.so有一個(gè)選項(xiàng)（exe=exec_mode），允許你指定如何處理可執(zhí)行文件的 POSIX EXECUTE 位。

• File ownership【文件所有權(quán)】

盡管 DOS 文件結(jié)構(gòu)不支持 user ID 和 group ID ，但是如果嘗試更改它們，fs-dos.so（默認(rèn)情況下）不會(huì)返回錯(cuò)誤代碼。 不返回錯(cuò)誤的原因，是因?yàn)樵S多實(shí)用程序會(huì)嘗試修改它們，并且如果失敗將導(dǎo)致意外錯(cuò)誤。 因此，采取的方法是“你可以把任何東西變成任何東西，因?yàn)樗凑粫?huì)寫入磁盤“。

posix=選項(xiàng)允許你設(shè)置更嚴(yán)格的 POSIX 檢查并啟用 POSIX 仿真。 例如，在 POSIX 模式下，嘗試執(zhí)行以下任一操作時(shí)，會(huì)標(biāo)記EINVAL錯(cuò)誤：

• • 將 User ID 或 Group ID 設(shè)置為 default （root） 的 root 對象。
  • 刪除 （r，read） 權(quán)限。
  • 設(shè)置 （s，set ID on execution） 權(quán)限。

如果將 posix 選項(xiàng)設(shè)置為（默認(rèn)） 或emulatestrict ，你將獲得以下好處：

• • .和..目錄項(xiàng)是在root目錄中創(chuàng)建。
  • 計(jì)算目錄大小。
  • 目錄中的鏈接數(shù)是根據(jù)其子目錄計(jì)算的。

1.8. FFS3文件系統(tǒng)

FFS3 文件系統(tǒng)驅(qū)動(dòng)程序?qū)崿F(xiàn)了 類似POSIX 的 NOR 閃存設(shè)備上的文件系統(tǒng)。驅(qū)動(dòng)程序是獨(dú)立的可執(zhí)行文件，既包含 Flash 文件系統(tǒng)代碼，又包含 Flash 設(shè)備代碼。對于不同的嵌入式系統(tǒng)硬件以及 PCMCIA 存儲(chǔ)卡，有不同 FFS3 文件系統(tǒng)驅(qū)動(dòng)程序的版本。

驅(qū)動(dòng)程序的命名約定是devf-system，其中system字段，描述嵌入式系統(tǒng)。

要了解我們目前支持的 Flash 設(shè)備， 請參閱以下來源：

• bsp_working_dir/src/hardware/flash 下的 boards 和 mtd-flash 目錄
• QNX Neutrino 實(shí)時(shí)操作系統(tǒng)文檔 （實(shí)用程序參考中的devf-*條目）
• BlackBerry QNX 網(wǎng)站 （www.qnx.com）

除了預(yù)構(gòu)建的 flash 文件系統(tǒng)驅(qū)動(dòng)程序外，還包括 “通用”驅(qū)動(dòng)程序 （devf-generic）。我們提供了構(gòu)建自定義Flash FileSystem 驅(qū)動(dòng)程序所需的庫和源代碼，用于不同的嵌入式系統(tǒng)。

1.8.1. 組織結(jié)構(gòu)【Organization】

FFS3 文件系統(tǒng)驅(qū)動(dòng)程序支持一個(gè)或多個(gè)邏輯 Flash 驅(qū)動(dòng)器。 每個(gè)邏輯驅(qū)動(dòng)器稱為一個(gè)socket【套接字】，它由一個(gè) Flash 內(nèi)存的連續(xù)且同構(gòu)的區(qū)域組成。例如，在包含兩種不同類型 Flash 器件（處于不同地址）的系統(tǒng)中，其中 1 個(gè) Flash 設(shè)備用于引導(dǎo)映像【boot image】另一個(gè)用于 flash 文件系統(tǒng)，每個(gè) flash 設(shè)備 將會(huì)出現(xiàn)在不同的socket【套接字】中。

每個(gè)socket【套接字】可以分為一個(gè)或多個(gè)分區(qū)。支持的兩個(gè)分區(qū)類型是：Raw Partitions【原始分區(qū)】和 Flash filesystem partitions【文件系統(tǒng)分區(qū)】。

Raw Partitions【原始分區(qū)】

套接字【socket】中的原始分區(qū)是不包含 flash 文件系統(tǒng)的任何分區(qū)的。 驅(qū)動(dòng)程序無法識別除 flash 文件系統(tǒng)以外的任何其他文件系統(tǒng)類型。 原始分區(qū)可能會(huì)包含image filesystem【映像文件系統(tǒng)】或一些特定于應(yīng)用程序的數(shù)據(jù)。

該FFS3文件系統(tǒng)，將會(huì)通過 raw mountpoint【原始掛載點(diǎn)】（見下文）訪問 flash 上的任何非 flash 分區(qū)。 請注意，flash 文件系統(tǒng)分區(qū)也可以作為 raw 分區(qū)使用。

Flash filesystem partitions【文件系統(tǒng)分區(qū)】

Flash 文件系統(tǒng)分區(qū)，包含了與 POSIX Flash filesystem 類似的文件系統(tǒng)，它使用一種 BlackBerry QNX 專有的格式，將文件系統(tǒng)數(shù)據(jù)存儲(chǔ)在 Flash 設(shè)備上。此格式與 Microsoft FFS2 或 PCMCIA FTL 規(guī)范不兼容。

該文件系統(tǒng)允許自由創(chuàng)建和刪除文件和目錄。 它使用與垃圾回收【reclaim mechanism】類似的回收機(jī)制，從已刪除的文件中回收存儲(chǔ)空間。

當(dāng)你啟動(dòng) flash 文件系統(tǒng)驅(qū)動(dòng)程序時(shí)，默認(rèn)情況下，它將會(huì)掛載它在套接字中所能找到的任何分區(qū)。 請注意，每個(gè) Flash 設(shè)備只能有一個(gè)驅(qū)動(dòng)程序?qū)嵗?#xff0c;并且你必須向驅(qū)動(dòng)程序提供 Flash 芯片的完整大小。 你可以使用mkefs或flashctl 指定掛載點(diǎn)（例如 /flash）。

掛載點(diǎn)	描述
/dev/fsX	原始掛載點(diǎn)套接字X
/dev/fsXpY	原始掛載點(diǎn)套接字X分區(qū)Y
/fsXpY	文件系統(tǒng)掛載點(diǎn)套接字X分區(qū)Y
/fsXpY/.cmp	文件系統(tǒng)壓縮的掛載點(diǎn)套接字X分區(qū)Y

1.8.2. 特征【Features】

FFS3 文件系統(tǒng)支持許多高級功能，例如 POSIX 兼容性， 多線程， 后臺(tái)回收【background reclaim】、故障恢復(fù)【fault recovery】、透明解壓【transparent decompression】、 字節(jié)序感知【endian-awareness】、磨損均衡【wear-leveling】和錯(cuò)誤處理【error-handling】。

POSIX

文件系統(tǒng)支持標(biāo)準(zhǔn)的 POSIX 功能（包括長文件名、訪問特權(quán)【access privileges】、隨機(jī)寫入【random writes】、truncation【截?cái)唷?和 symbolic links【符號鏈接】），但以下情況除外：

• 你無法創(chuàng)建硬鏈接【hard links】。
• 訪問時(shí)間不受支持（但支持文件修改時(shí)間和屬性更改時(shí)間）。

這些設(shè)計(jì)上的妥協(xié)，使這個(gè)文件系統(tǒng)保持小而簡單，但通常包含了塊設(shè)備文件系統(tǒng)能夠找到的大多數(shù)功能。

@>> 閱讀擴(kuò)展：

truncation指的是調(diào)整文件大小的功能?。?具體來說，?truncation操作可以刪除文件中從某個(gè)位置開始到文件末尾的數(shù)據(jù)，?使得文件大小發(fā)生變化。?在這個(gè)過程中，?被截?cái)嗖糠种罢加玫臄?shù)據(jù)塊會(huì)被釋放，?以供其他文件使用。?此操作對于管理文件存儲(chǔ)空間、?優(yōu)化文件系統(tǒng)等具有重要意義。?在Linux文件系統(tǒng)中，?truncation操作可以通過特定的系統(tǒng)調(diào)用或命令來實(shí)現(xiàn)，?如truncate命令。?該命令允許用戶將文件大小縮小或擴(kuò)展到指定的大小，?如果文件大于指定的大小，?則會(huì)丟失額外的數(shù)據(jù)；?如果文件較短，?則會(huì)被擴(kuò)展，?擴(kuò)展部分的內(nèi)容為零字節(jié)?。

存儲(chǔ)效率

文件系統(tǒng)對存儲(chǔ)在文件系統(tǒng)上的每個(gè)用戶數(shù)據(jù)塊使用固定大小的32字節(jié)區(qū)段頭。文件系統(tǒng)有一個(gè)512字節(jié)的“append buffer”，用于把 small append 合并到文件，然后再將其刷新到磁盤。 文件系統(tǒng)中沒有其他的用戶數(shù)據(jù)緩存（讀取或?qū)懭?#xff09;。 盡管mkefs可以創(chuàng)建16 KB的 extents【數(shù)據(jù)區(qū)段】，但是對于在運(yùn)行時(shí)所創(chuàng)建的文件，目前最大 extent 大小被限制為 4096 字節(jié)的數(shù)據(jù)（加上32字節(jié)header）。

@>> 閱讀擴(kuò)展：

文件系統(tǒng)的extents表示一組連續(xù)的數(shù)據(jù)塊（?通常是磁盤塊或頁）?，?它們按順序分配給文件或數(shù)據(jù)結(jié)構(gòu)?。?這一概念用于描述一種用于組織和分配數(shù)據(jù)存儲(chǔ)空間的方式，?旨在提高文件系統(tǒng)的性能并減少文件碎片。?

• ?連續(xù)性?：?一個(gè)extent是一個(gè)連續(xù)的數(shù)據(jù)塊范圍，?有助于提高讀取和寫入性能。?
• ?分配策略?：?文件系統(tǒng)或存儲(chǔ)管理系統(tǒng)通常會(huì)分配一個(gè)或多個(gè)連續(xù)的extent來容納文件的數(shù)據(jù)。?
• ?大小可變?：?extent的大小可以根據(jù)存儲(chǔ)系統(tǒng)的配置和策略而變化。?
• ?元數(shù)據(jù)?：?存儲(chǔ)管理系統(tǒng)會(huì)維護(hù)關(guān)于extent的元數(shù)據(jù)，?包括數(shù)據(jù)塊偏移量、?大小和位置等信息。?
• 文件系統(tǒng)支持：extent 是一種在現(xiàn)代文件系統(tǒng)中廣泛使用的分配策略。一些文件系統(tǒng)，如 Btrfs、XFS 和 ZFS，使用 extent 作為它們的默認(rèn)分配單元，以提高性能和管理數(shù)據(jù)。

總之，extent 是一種用于管理存儲(chǔ)空間和提高文件系統(tǒng)性能的方法，它通過分配連續(xù)的數(shù)據(jù)塊范圍來減少文件碎片。這對于文件系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)和其他需要大規(guī)模數(shù)據(jù)存儲(chǔ)的應(yīng)用程序非常有用。

磨損均衡

磨損均衡是在給定分區(qū)內(nèi)的塊上執(zhí)行的。 如果 flash 被拆分為多個(gè)分區(qū)，則每個(gè)分區(qū)都有一個(gè) 較小的池要均衡訪問。 塊永遠(yuǎn)不會(huì)從一個(gè)分區(qū)遷移到另一個(gè)分區(qū)。

前臺(tái)回收是文件系統(tǒng)中最常見的回收類型，總是會(huì)執(zhí)行雙重回收操作。 第一重回收總是查找分區(qū)中擦除計(jì)數(shù)最少的塊，并將其與備用塊進(jìn)行交換。 然后是第二重回收，將需要回收的塊將與備用塊進(jìn)行交換。 事實(shí)證明，當(dāng)使用前臺(tái)回收時(shí)，會(huì)導(dǎo)致近乎完美的磨損均衡。

后臺(tái)回收

FFS3 文件系統(tǒng)會(huì)把文件和目錄存儲(chǔ)為extents【數(shù)據(jù)區(qū)段】的鏈接列表，這些extents【數(shù)據(jù)區(qū)段】被標(biāo)記為要?jiǎng)h除狀態(tài)，則它們將會(huì)被刪除或更新。要回收的 extents 會(huì)使用一種簡單的算法來進(jìn)行選擇，該算法會(huì)查找具有要回收的最大空間的塊，同時(shí)保持每個(gè)單獨(dú)塊的磨損量水平。 這種磨損均衡可以增加 Flash 設(shè)備的 MTBF（平均故障間隔時(shí)間），從而延長其使用壽命。

當(dāng)沒有足夠的可用空間時(shí)，將執(zhí)行后臺(tái)回收過程。 后臺(tái)回收過程首先會(huì)將待回收塊的內(nèi)容復(fù)制到一個(gè)空的備用塊中，然后使用該備用塊替換待回收塊。再然后，待回收塊會(huì)被擦除。與帶有機(jī)械磁頭的旋轉(zhuǎn)存儲(chǔ)介質(zhì)原理不同，數(shù)據(jù)分布的接近性并不是 Flash 文件系統(tǒng)性能的一個(gè)因素，因此數(shù)據(jù)可以分散在介質(zhì)上，而不會(huì)降低性能。

故障恢復(fù)

該文件系統(tǒng)旨在最大程度地減少由于意外斷電故障而導(dǎo)致的損壞。 對 extent headers 及 erase block headers 的更新，始終按照經(jīng)過謹(jǐn)慎計(jì)劃的順序進(jìn)行執(zhí)行。 這些步驟允許在數(shù)據(jù)損壞的情況下恢復(fù)文件系統(tǒng)的完整性。

請注意，對于有效的故障恢復(fù)系統(tǒng)，正確設(shè)計(jì)的 Flash 硬件是至關(guān)重要的。 特別是，必須有特殊的復(fù)位電路，以便在電源電壓跌落至某臨界值以下之前，使系統(tǒng)保持在“復(fù)位”狀態(tài)。 否則，虛假或隨機(jī)的總線活動(dòng)會(huì)形成寫入/擦除命令，并損壞閃存，從而造成無法恢復(fù)。

重命名操作保證是原子的，即使發(fā)生斷電故障也是如此。 這意味著，例如，如果你在為映像或可執(zhí)行文件指定新名稱時(shí)斷電， 恢復(fù)后，你仍然可以通過其舊名稱訪問文件。

當(dāng) FFS3 文件系統(tǒng)驅(qū)動(dòng)程序啟動(dòng)時(shí)，從 簡單的塊的回收 到 擦除懸空的 extent 鏈接，它會(huì)掃描介質(zhì)上每個(gè) extent header 的狀態(tài)（以便驗(yàn)證其完整性），并采取適當(dāng)?shù)拇胧?此過程與文件系統(tǒng)的正常掛載過程合并，以實(shí)現(xiàn)最佳的引導(dǎo)計(jì)時(shí)。

壓縮和解壓縮

為了快速有效地壓縮/解壓縮，你可以使用deflate和inflator實(shí)用程序，它們依賴于流行的 deflate/inflate 算法。

deflate算法結(jié)合了兩種算法。第一個(gè)算法負(fù)責(zé)刪除文件中的數(shù)據(jù)重復(fù)；第二個(gè)算法通過給它們分配更短的符號，處理出現(xiàn)頻率最高的數(shù)據(jù)序列。這兩種算法提供了出色的數(shù)據(jù)及可執(zhí)行文件的無損壓縮。而inflate算法只是簡單地反向執(zhí)行了deflate算法所做的事情。

deflate實(shí)用程序旨在與mkefs的filter屬性一起使用。 你還可以使用它來預(yù)壓縮文件用于 Flash 文件系統(tǒng)。

inflate資源管理器位于其他文件系統(tǒng)之前，該文件系統(tǒng)先前使用deflate實(shí)用程序?qū)ξ募M(jìn)行了壓縮。 它幾乎可以使 flash 的有效空間增加一倍。

壓縮文件可以使用cp或ftp等標(biāo)準(zhǔn)實(shí)用程序進(jìn)行操作，如果對正確的掛載點(diǎn)使用ls實(shí)用程序，可以顯示其壓縮后大小和未壓縮的大小。這些功能使得系統(tǒng)設(shè)計(jì)師對壓縮的 Flash 文件系統(tǒng)可以進(jìn)行無縫管理。

Flash 錯(cuò)誤

隨著 flash 硬件的磨損，其寫入狀態(tài)機(jī)可能會(huì)發(fā)現(xiàn)它無法再寫入或擦除某些特定的 bit cell【比特單元】。當(dāng)發(fā)生這種情況時(shí)，錯(cuò)誤狀態(tài)會(huì)被傳回 flash 驅(qū)動(dòng)程序，以便它可以采取適當(dāng)?shù)牟僮?#xff08;也就是，標(biāo)記 bad 區(qū)域，并嘗試在另一個(gè)位置進(jìn)行寫入或擦除）。

此錯(cuò)誤處理機(jī)制是透明的。 請注意，在發(fā)生多次 Flash 錯(cuò)誤之后，所有失敗的寫入和擦除操作最終會(huì)造成 Flash 被呈現(xiàn)為只讀狀態(tài)。幸運(yùn)的是，在多年的 flash 操作之前這種情況不應(yīng)該會(huì)發(fā)生。 檢查你的 Flash 規(guī)格并分析應(yīng)用程序到 Flash 的數(shù)據(jù)流，可以計(jì)算其潛在壽命或 MTBF。

字節(jié)序感知

FFS3 文件系統(tǒng)具有字節(jié)序感知功能，因此可以跨不同平臺(tái)進(jìn)行移植。 推薦的最佳方法是，使用 mkefs 實(shí)用程序選擇目標(biāo)字節(jié)序。

1.8.3. 實(shí)用程序【Utilities】

文件系統(tǒng)支持所有標(biāo)準(zhǔn)的 POSIX 實(shí)用程序，比如ls，mkdir，rm，ln，mv，和cp等。還有一些特定于 QNX Neutrino 的實(shí)用程序也可以用于管理 falsh：

• flashctl

擦除、格式化和掛載 Flash 分區(qū)。

• deflate

壓縮 Flash 文件系統(tǒng)的文件。

• mkefs

創(chuàng)建 Flash 文件系統(tǒng)映像文件。

1.8.4. 系統(tǒng)調(diào)用【System calls】

該文件系統(tǒng)支持所有標(biāo)準(zhǔn)的 POSIX I/O 函數(shù)，例如?open()，close()，read()，以及?write()?等。 使用非 POSIX 的?devctl()?函數(shù)支持擦除等特殊功能。

1.9. NFS文件系統(tǒng)

網(wǎng)絡(luò)文件系統(tǒng)（NFS）允許客戶端工作站通過網(wǎng)絡(luò)執(zhí)行透明的文件訪問。它允許客戶端工作站跨各種操作系統(tǒng)對駐留在服務(wù)器上的文件進(jìn)行操作。客戶端對文件的訪問調(diào)用會(huì)轉(zhuǎn)換為NFS協(xié)議請求，并通過網(wǎng)絡(luò)發(fā)送給服務(wù)器。服務(wù)器在接收到請求后，執(zhí)行實(shí)際的文件系統(tǒng)操作，并將響應(yīng)結(jié)果發(fā)送回客戶端。

網(wǎng)絡(luò)文件系統(tǒng)通過使用遠(yuǎn)程程序調(diào)用（RPC）以及TCP/IP 進(jìn)行傳輸，以無狀態(tài)方式進(jìn)行運(yùn)行。因此，要使用fs-nfs3，還需要為 QNX Neutrino 運(yùn)行 TCP/IP 客戶端。

在遠(yuǎn)程服務(wù)器文件系統(tǒng)中的任何 POSIX 限制，都會(huì)被傳遞給客戶端。例如，文件名的長度可能因服務(wù)器的不同操作系統(tǒng)而有所不同。version 3 版本的 NFS 將文件名長度限制為了 255 個(gè)字符；而 version 1 和 version 3 版本的mountd將路徑名長度限制為1024個(gè)字符。

1.10. CIFS文件系統(tǒng)

CIFS（Common Internet File System，通用互聯(lián)網(wǎng)文件系統(tǒng)，以前稱為SMB）允許客戶端工作站通過網(wǎng)絡(luò)對運(yùn)行SMB服務(wù)器的 Windows 系統(tǒng)或 UNIX 系統(tǒng)執(zhí)行透明的文件訪問?？蛻舳藢ξ募脑L問調(diào)用會(huì)被轉(zhuǎn)換為CIFS協(xié)議請求，通過網(wǎng)絡(luò)發(fā)送給服務(wù)器。服務(wù)器在接收到請求后，執(zhí)行實(shí)際的文件系統(tǒng)操作，并將響應(yīng)發(fā)送回客戶客戶端。

CIFS協(xié)議未試圖與POSIX保持一致。

fs-cifs管理器使用TCP/IP進(jìn)行傳輸。因此，要使用fs-cifs，還需要為QNX Neutrino RTOS運(yùn)行TCP/IP客戶端。

1.11. Linux Ext2文件系統(tǒng)

Ext2文件系統(tǒng)提供對Linux磁盤分區(qū)的透明訪問。

fs-ext2.so實(shí)現(xiàn)了支持Ext2的 version 0 和 version 1 版本中的標(biāo)準(zhǔn)功能集。

對稀疏文件的支持也包含在內(nèi)，是為了與現(xiàn)有的Linux分區(qū)兼容。其他文件系統(tǒng)只能在稀疏文件之上“堆疊”為只讀。普通文件沒有這樣的限制。

@>> 閱讀擴(kuò)展：?

稀疏文件是一種特殊類型的計(jì)算機(jī)文件，?旨在更有效地使用文件系統(tǒng)的空間?。?

• ?定義?：?稀疏文件是一種計(jì)算機(jī)文件，?當(dāng)文件內(nèi)容大多為空時(shí)，?它嘗試更有效地使用文件系統(tǒng)的空間。?
• ?原理?：?稀疏文件使用簡短的信息（?元數(shù)據(jù)）?來表示空數(shù)據(jù)塊，?而不是在磁盤上占用實(shí)際空間來存儲(chǔ)空數(shù)據(jù)塊。?只有真實(shí)（?非空）?的數(shù)據(jù)塊會(huì)按原樣寫入磁盤。?
• ?讀取方式?：?在讀取稀疏文件時(shí)，?文件系統(tǒng)會(huì)根據(jù)元數(shù)據(jù)在運(yùn)行時(shí)將這些空數(shù)據(jù)塊轉(zhuǎn)換為“真實(shí)”的數(shù)據(jù)塊，?即填充為零，?應(yīng)用程序不會(huì)察覺這個(gè)轉(zhuǎn)換。?
• ?應(yīng)用場景?：?稀疏文件常用于數(shù)據(jù)庫文件、?虛擬機(jī)文件等場景，?可以有效減少物理磁盤的占用?。

?其他文件系統(tǒng)只能以只讀的方式“堆疊”在稀疏文件之上，?而對于普通文件則沒有這樣的限制?。?

具體來說，?“堆疊”在這里可能指的是將另一個(gè)文件系統(tǒng)疊加在當(dāng)前文件系統(tǒng)之上，?以便同時(shí)訪問兩個(gè)文件系統(tǒng)的內(nèi)容。?然而，?當(dāng)涉及到稀疏文件時(shí)，?這種堆疊操作只能以只讀方式進(jìn)行，?這可能是為了防止對稀疏文件結(jié)構(gòu)的破壞或數(shù)據(jù)丟失。?

相比之下，?對于普通文件，?沒有這樣的堆疊限制，?可以自由地以讀寫方式訪問和修改它們。?

如果Ext2文件系統(tǒng)沒有正確卸載，則文件系統(tǒng)檢查器通常會(huì)在下次掛載文件系統(tǒng)時(shí)負(fù)責(zé)清理。雖然fs-ext2.so模塊配備了執(zhí)行快速測試的功能，如果檢測到任何（應(yīng)該使用文件系統(tǒng)檢查器修復(fù)的）重大問題，它會(huì)自動(dòng)將文件系統(tǒng)掛載為只讀狀態(tài)。

1.12. 通用磁盤格式（UDF）文件系統(tǒng)

通用磁盤格式（UDF）文件系統(tǒng)提供對可記錄媒體的訪問，例如CD、CD-R、CD-RW和DVD。它可以用于DVD視頻，但也可以用于備份數(shù)據(jù)到CD，等等。欲了解更多信息，請?jiān)L問 OSTA Universal Disk Format Specifications。

在我們的實(shí)現(xiàn)中，UDF文件系統(tǒng)是只讀的。

1.13. 蘋果麥金塔 HFS 和 HFS Plus

蘋果麥金塔 HFS（Hierarchical File System，分級文件系統(tǒng)）和 HFS Plus 是蘋果麥金塔系統(tǒng)上的文件系統(tǒng)。

fs-mac.so共享對象，提供了對 QNX Neutrino 系統(tǒng)上的 HFS 和 HFS Plus 磁盤的只讀訪問。該程序可以識別以下變體：HFS、HFS Plus、HFSJ（HFS Plus with journal，帶日志的HFS Plus）、HFS包裝器中的HFS Plus、HFSX（區(qū)分大小寫）和 HFS/ISO-9660 混合型。在QNX Neutrino 7.0.4或更高版本中，你也可以用熱日志（或臟日志）掛載 HFSJ 文件系統(tǒng)。

1.14. Windows NT文件系統(tǒng)

NT文件系統(tǒng)用于 Microsoft Windows NT 及更高版本。

fs-nt.so共享對象，提供了對 QNX Neutrino 系統(tǒng)上的 NTFS 磁盤的只讀訪問。

1.15. 解壓縮直通文件系統(tǒng)

QNX Neutrino 提供了一個(gè)解壓縮直通文件系統(tǒng)【Inflator pass-through filesystem】，它是一個(gè)位于其他文件系統(tǒng)前面的資源管理器，可以（使用deflate實(shí)用程序）對以前被壓縮的文件進(jìn)行解壓。

當(dāng)?shù)讓游募到y(tǒng)是 flash 文件系統(tǒng)時(shí)，通常會(huì)結(jié)合inflator實(shí)用程序進(jìn)行使用，幾乎可以使 flash 的有效空間增加一倍。

如果正在打開文件進(jìn)行讀取，則inflator將嘗試在底層文件系統(tǒng)上打開該文件本身。它讀取前16個(gè)字節(jié)并檢查壓縮文件的簽名。如果文件被壓縮，inflator會(huì)將自己置于應(yīng)用程序和底層文件系統(tǒng)之間。所有讀操作都返回文件被壓縮之前的原始數(shù)據(jù)。

從應(yīng)用程序的角度來看，文件似乎是未壓縮的。也支持隨機(jī)查找。如果應(yīng)用程序?qū)ξ募?zhí)行stat()操作，則會(huì)返回解壓后的文件的大小（也就是文件被壓縮前的原始大小）。

在重疊的路徑名空間上運(yùn)行多個(gè)直通文件系統(tǒng)或資源管理器可能會(huì)導(dǎo)致死鎖。

1.16. QNX可信磁盤

QNX可信磁盤（QTD，QNX Trusted Disk）設(shè)備，在安全引導(dǎo)環(huán)境中，為底層磁盤數(shù)據(jù)提供完整性保護(hù)。它們可以將安全引導(dǎo)鏈擴(kuò)展到核心操作系統(tǒng)的文件系統(tǒng)中，在該文件系統(tǒng)中存儲(chǔ)有關(guān)鍵二進(jìn)制文件和配置文件。

QTD保護(hù)機(jī)制基于哈希樹（Merkle tree），由fs-qtd.so共享對象進(jìn)行支持。

在構(gòu)建QTD映像時(shí)，會(huì)從源文件系統(tǒng)映像的塊中構(gòu)造元數(shù)據(jù)哈希樹【metadata hash tree】。

@>> 閱讀擴(kuò)展：?

Merkle Tree是一種基于哈希的樹狀數(shù)據(jù)結(jié)構(gòu)?。?以下是關(guān)于Merkle Tree的詳細(xì)解釋：?

• ?定義?：?Merkle Tree，?又稱哈希樹，?是一種持久性數(shù)據(jù)結(jié)構(gòu)，?用于實(shí)現(xiàn)集合和映射，?旨在替換純函數(shù)式編程中的哈希表。?
• ?結(jié)構(gòu)?：?在Merkle Tree中，?每個(gè)葉子節(jié)點(diǎn)代表一個(gè)數(shù)據(jù)塊（?如文件或文件集合）?的哈希值，?每個(gè)非葉子節(jié)點(diǎn)是其子節(jié)點(diǎn)哈希值的哈希。?通常，?Merkle Tree的分支因子為2，?即每個(gè)節(jié)點(diǎn)最多有2個(gè)子節(jié)點(diǎn)。?
• ?應(yīng)用?：?Merkle Tree在密碼學(xué)、?分布式系統(tǒng)和區(qū)塊鏈等領(lǐng)域得到廣泛應(yīng)用。?在區(qū)塊鏈中，?它用于驗(yàn)證交易和區(qū)塊的完整性，?確保數(shù)據(jù)不被篡改，?從而提高區(qū)塊鏈的可擴(kuò)展性和安全性?。

QTD磁盤設(shè)備是只讀的。QTD驅(qū)動(dòng)程序位于原始塊設(shè)備和受支持的上層文件系統(tǒng)層之間（例如，由fs-qnx6.so進(jìn)行支持的Power-Safe文件系統(tǒng)）。在讀訪問時(shí)，它使用哈希樹元數(shù)據(jù)【hash tree metadata】來驗(yàn)證數(shù)據(jù)的完整性。如果驗(yàn)證失敗，則返回錯(cuò)誤。

使用密鑰對【key pair】對QTD元數(shù)據(jù)進(jìn)行簽名和驗(yàn)證。對簽名進(jìn)行驗(yàn)證可以確保樹的根哈希是有效的，并且沒有被篡改。它是可信驗(yàn)證機(jī)制的根。

QTD 映像的大小取決于所選擇的塊大小以及所選擇的摘要算法【digest algorithm】。可以使用mkqfs實(shí)用程序生成統(tǒng)計(jì)信息，描述元數(shù)據(jù)消耗了多少額外的空間。

1.16.1. 使用QTD作為受保護(hù)的容器（應(yīng)用模型）

通過掛載一個(gè)本身就是QTD映像的文件，你可以將QTD用作 package container 的解決方案。請參見實(shí)用程序參考中的fs-qtd.so項(xiàng)。

1.16.2. 安全散列算法（SHA）

根據(jù)你目標(biāo)的架構(gòu)和摘要函數(shù)所需的安全強(qiáng)度，請你參考下表，選擇性能最佳的算法。并對你的系統(tǒng)進(jìn)行基準(zhǔn)測試以確定最佳組合。

Architecture【架構(gòu)】	Digest security【摘要的安全性】
	128 bits	256 bits
32-bit	sha256 blake2s256 blake3	sha512 blake2b512
64-bit	sha512?256 blake2b256 blake3	sha512 blake2b512

@>> 閱讀擴(kuò)展：

Secure Hash Algorithms（?SHA）?，即安全散列算法，是一個(gè)密碼散列函數(shù)家族，能計(jì)算出一個(gè)數(shù)字消息所對應(yīng)到的，長度固定的字符串（又稱消息摘要）的算法。且若輸入的消息不同，它們對應(yīng)到不同字符串的幾率很高。SHA是由美國國家安全局（?NSA）?開發(fā)的算法家族，?用于保障數(shù)據(jù)的安全性和完整性。?SHA算法能將接收到的消息通過哈希算法轉(zhuǎn)換成固定位數(shù)的哈希值（?也稱消息摘要）?，?用于驗(yàn)證數(shù)據(jù)的完整性。?SHA算法經(jīng)歷了多個(gè)版本的更新，?包括SHA1、?SHA2、?SHA3等，?其中SHA1已經(jīng)被破解，?目前使用比較廣泛的是SHA2類，?如SHA256。?SHA算法主要應(yīng)用于各種網(wǎng)絡(luò)安全和數(shù)據(jù)加密領(lǐng)域，?如數(shù)字簽名標(biāo)準(zhǔn)（?DSS）?里面定義的數(shù)字簽名算法（?DSA）?，?以及汽車ECU中重要數(shù)據(jù)的保護(hù)等?。

1.16.3. 簽名密鑰【Signing keys】

有關(guān)支持的密鑰類型和簽名算法，請參閱mkqfs實(shí)用程序。

1.16.4. 加密引擎【Crypto engines】

QTD使用通過QNX加密庫（qcrypto）提供的加密算法。它可以使用任何支持所選摘要算法和簽名類型的qcrypto插件。有關(guān)更多信息，請參閱系統(tǒng)安全指南中的“QNX Cryptography Library”。

1.17. 文件系統(tǒng)事件

對于使用它的程序來說，跟上一個(gè)經(jīng)?？焖僮兓姆浅！盎钴S”的文件系統(tǒng)是一個(gè)挑戰(zhàn)。為了幫助解決這個(gè)問題，QNX Neutrino包含了文件系統(tǒng)事件。

這些事件使得應(yīng)用程序能夠跟蹤相關(guān)文件系統(tǒng)中的更改，包括文件和目錄的創(chuàng)建和刪除、所有權(quán)和權(quán)限的更改、掛載和卸載操作等等。對文件系統(tǒng)事件的管理，涉及到一個(gè)事件管理器、一個(gè)事件機(jī)制和客戶端事件處理程序。

事件管理器fsevmgr是一個(gè)進(jìn)程，它會(huì)在系統(tǒng)名稱空間中注冊一個(gè)固定的名稱（默認(rèn)為/dev/fsevents），并在該路徑上接收文件系統(tǒng)事件（可能來自多個(gè)io-blk.so實(shí)例），從而確定哪些客戶端需要哪些事件，并將事件提供給這些客戶端。

事件機(jī)制是io-blk.so的一部分，任何的文件系統(tǒng)，或者塊I/O系統(tǒng)部分，都可以輕松地使用它。這種方式提供了最大的靈活性，因?yàn)槲覀兛梢栽谙到y(tǒng)調(diào)用級別協(xié)調(diào)事件進(jìn)入文件系統(tǒng)，這些事件可能來自文件系統(tǒng)內(nèi)部、分區(qū)、緩存甚至塊設(shè)備驅(qū)動(dòng)程序（如果需要的話）。

該機(jī)制會(huì)將事件先放入緩沖區(qū)，然后最終發(fā)送給事件管理器。這種機(jī)制僅限于用于報(bào)告事件來源的API、指示事件的唯一標(biāo)識符，以及進(jìn)一步描述事件的屬性。io-blk.so庫負(fù)責(zé)打包每個(gè)事件并將其發(fā)送給事件管理器。該實(shí)現(xiàn)使用定時(shí)器來確保事件不會(huì)在此緩沖區(qū)中停留很長時(shí)間。

在啟動(dòng)時(shí)，io-blk.so尋找事件管理器。如果事件管理器未加載，則禁用事件機(jī)制。所提供的三個(gè)配置參數(shù)如下所示：

• fse-device — 事件管理器的名稱
• fse-period — 在事件被發(fā)送到事件管理器之前延遲的最大時(shí)間
• fse-size — 保存事件的緩沖區(qū)的大小

在加載事件管理器期間，devctl命令DCMD_FSYS_FSEVMGR_CHECK會(huì)被發(fā)送到各個(gè)io-blk.so掛載點(diǎn)，通知它們事件管理器已經(jīng)加載完成。

最后，客戶端事件處理程序可以實(shí)例化一個(gè)線程，該線程需要進(jìn)入阻塞狀態(tài)從/dev/fsevents讀取數(shù)據(jù)，或者在數(shù)據(jù)可用時(shí)選擇文件描述符進(jìn)行通知。

以下是客戶端通常如何與事件管理器交互的概述：

• open()

FSE_DEFAULT_MANAGER_NAME（在<sys/fs_events.h>中定義）描述了事件管理器的默認(rèn)路徑。請記住，它可能被事件管理器覆蓋【overridden 】，并且io-blk.so也可能會(huì)轉(zhuǎn)而尋找另一個(gè)事件管理器。

客戶端通常應(yīng)該以O_RDONLY模式打開事件管理器，以便簡單地讀取事件。只有當(dāng)客戶端需要發(fā)送事件時(shí)，才需要寫模式。如果客戶端要輪詢事件管理器，則設(shè)置O_NONBLOCK標(biāo)志。

• read()

客戶端將事件從事件管理器讀取到字節(jié)數(shù)組中。字節(jié)數(shù)組被填充到存儲(chǔ)整個(gè)事件所需的大小。換句話說，部分事件不會(huì)返回給讀取者。不能對緩沖區(qū)內(nèi)事件的對齊進(jìn)行任何假設(shè)。

FSE_READ_EVENT_S(pev, pbytes)作為包裝器提供給memcpy()從字節(jié)數(shù)組到對齊結(jié)構(gòu)的事件。從那里，客戶端可以使用其他FSE_*訪問器宏來解釋事件特征。

雖然事件管理器通常會(huì)有一個(gè)大的隊(duì)列來容納事件，但不可避免地，它如果被填滿將會(huì)開始覆蓋舊事件。如果任何事件客戶端沒有跟上新事件的添加速度，那么這些讀取器將會(huì)被置于溢出狀態(tài)。換句話說，如果事件管理器已經(jīng)開始覆蓋讀取器尚未使用的事件，則從該描述符讀取的下一次讀取開始，將會(huì)指示EOVERFLOW錯(cuò)誤。隨后的read()操作會(huì)返回當(dāng)前隊(duì)列中最早的事件。

• lseek()

事件管理器支持有限的查找功能。通常，客戶端從隊(duì)列的頭部開始讀取，并且立即阻塞和等待新事件。如果客戶端必須評估過去的事件，則可以使用lseek()。

使用SEEK_SET作為whence的值并將偏移量設(shè)置為零，?可將文件描述符定位到隊(duì)列中最早的事件。?請注意，這種情況可能會(huì)在隨后的read()中導(dǎo)致EOVERFLOW錯(cuò)誤。

使用SEEK_END作為whence的值并將偏移量設(shè)置為零，?可將讀取器定位到隊(duì)列末尾以讀取新事件。?

客戶端可以使用事件計(jì)數(shù)值作為偏移量，使用SEEK_SET或SEEK_END分別從隊(duì)列的頭部或尾部，索引一些事件的計(jì)數(shù)值。

• write()

客戶端可以使用write()將事件發(fā)送到事件管理器。事件管理器檢查事件數(shù)據(jù)以確保其格式良好；如果檢查失敗，事件管理器將會(huì)終止在單次寫操作中所發(fā)送的所有事件的寫操作的執(zhí)行。

• close()

如果一旦不再需要文件描述符，則可能就會(huì)需要被關(guān)閉。

頭文件<sys/fs_events.h>中包含了從事件管理器讀取以及處理事件所需的所有內(nèi)容。有關(guān)更多信息，請參閱 C 庫參考中的 FSE_*() 的內(nèi)容。