การออกแบบระบบไฟล์ FAT

ระบบไฟล์ FATเป็นระบบไฟล์ที่ใช้ในระบบปฏิบัติการMS-DOSและ Windows 9x ^{[ 3 ]}ยังคงมีการใช้งานในอุปกรณ์เคลื่อนที่และระบบฝังตัวดังนั้นจึงเป็นระบบไฟล์ที่เหมาะสมสำหรับการแลกเปลี่ยนข้อมูลระหว่างคอมพิวเตอร์และอุปกรณ์เกือบทุกประเภทและทุกยุคสมัยตั้งแต่ปี 1981 จนถึงปัจจุบัน

ระบบไฟล์ FAT ประกอบด้วยสี่ส่วน:

FAT ใช้ รูปแบบ little-endianสำหรับรายการทั้งหมดในส่วนหัว (ยกเว้นบางรายการในเซกเตอร์บูตของ Atari ST ที่ระบุไว้อย่างชัดเจน) และ FAT ^{[ 5 ]}สามารถจัดสรรเซกเตอร์ FAT ได้มากกว่าจำนวนคลัสเตอร์ที่จำเป็น ส่วนท้ายของเซกเตอร์สุดท้ายของแต่ละสำเนา FAT อาจไม่ได้ใช้งานหากไม่มีคลัสเตอร์ที่สอดคล้องกัน จำนวนเซกเตอร์ทั้งหมด (ตามที่ระบุไว้ในเรคอร์ดบูต) อาจมากกว่าจำนวนเซกเตอร์ที่ใช้โดยข้อมูล (คลัสเตอร์ × เซกเตอร์ต่อคลัสเตอร์) FAT (จำนวน FAT × เซกเตอร์ต่อ FAT) ไดเร็กทอรีรูท (ไม่มีใน FAT32) และเซกเตอร์ที่ซ่อนอยู่รวมถึงเซกเตอร์บูต: ซึ่งจะส่งผลให้มีเซกเตอร์ที่ไม่ได้ใช้งานที่ส่วนท้ายของวอลุ่ม หากพาร์ติชันมีเซกเตอร์มากกว่าจำนวนเซกเตอร์ทั้งหมดที่ระบบไฟล์ครอบครอง ก็จะส่งผลให้มีเซกเตอร์ที่ไม่ได้ใช้งานที่ส่วนท้ายของพาร์ติชันหลังจากวอลุ่มเช่นกัน

สำหรับ อุปกรณ์จัดเก็บข้อมูลที่ไม่ได้แบ่ง พาร์ติชั่น เช่นฟลอปปี้ดิสก์เซกเตอร์บูต ( VBR )คือเซกเตอร์แรก (เซกเตอร์เชิงตรรกะ 0 ที่มีแอดเดรส CHS ทางกายภาพ 0/0/1 หรือแอดเดรส LBA 0) สำหรับอุปกรณ์จัดเก็บข้อมูลที่แบ่งพาร์ติชั่น เช่น ฮาร์ดดิสก์ เซกเตอร์บูตคือเซกเตอร์แรกของพาร์ติชั่น ตามที่ระบุไว้ในตารางพาร์ติชั่นของอุปกรณ์

DOS 3.0 BPB:

ส่วนขยายต่อไปนี้ได้รับการบันทึกไว้ตั้งแต่ DOS 3.0 อย่างไรก็ตาม ส่วนขยายเหล่านี้ได้รับการสนับสนุนแล้วใน DOS 2.11 บางฉบับ^{[ 28 ]} MS-DOS 3.10 ยังคงรองรับรูปแบบ DOS 2.0 แต่สามารถใช้รูปแบบ DOS 3.0 ได้เช่นกัน

DOS 3.2 BPB:

อย่างเป็นทางการแล้ว MS-DOS 3.20 ยังคงใช้รูปแบบของ DOS 3.0 แต่SYSได้FORMATมีการปรับเปลี่ยนเพื่อให้รองรับรูปแบบที่ยาวขึ้นอีก 6 ไบต์ (ซึ่งไม่ได้ใช้ทุกรายการ)

DOS 3.31 BPB:

รูปแบบนี้ถูกนำมาใช้อย่างเป็นทางการใน DOS 3.31 และไม่ได้ใช้ใน DOS 3.2 อย่างไรก็ตาม โปรแกรมยูทิลิตี้บางตัวใน DOS 3.2 ได้รับการออกแบบให้รองรับรูปแบบใหม่นี้อยู่แล้ว เอกสารอย่างเป็นทางการแนะนำให้เชื่อถือค่าเหล่านี้เฉพาะในกรณีที่ค่าในช่องตรรกะที่ตำแหน่งออฟเซ็ต0x013เป็นศูนย์เท่านั้น

สูตรง่ายๆ แปลงหมายเลขคลัสเตอร์ที่กำหนดของวอลุ่มCNเป็นหมายเลขเซกเตอร์เชิงตรรกะLSN: ^{[ 24 ] [ 25 ] [ 26 ]}

1. กำหนดค่า (เพียงครั้งเดียว) โดยที่จำนวนเซกเตอร์ที่สงวนไว้จะถูกจัดเก็บไว้ที่ออฟเซ็ต0x00Eจำนวน FAT ที่ออฟเซ็ต0x010จำนวนเซกเตอร์ต่อ FAT ที่ออฟเซ็ต0x016 (FAT12/FAT16) หรือ0x024 (FAT32) รายการในไดเร็กทอรีรูทที่ออฟเซ็ต0x011ขนาดเซกเตอร์ที่ออฟเซ็ต0x00Bและปัดเศษขึ้นเป็นจำนวนเต็มSSA=RSC+FN×SF+ceil((32×RDE)/SS)RSCFNSFRDESSceil(x)
2. กำหนด ตำแหน่งที่ จัดเก็บเซกเตอร์ต่อคลัสเตอร์ ไว้ที่ออฟเซ็ ต0x00DLSN=SSA+(CN−2)×SCSC

ในสื่อที่ไม่ได้แบ่งพาร์ติชั่น จำนวนเซกเตอร์ที่ซ่อนอยู่ของวอลุ่มจะเป็นศูนย์ ดังนั้นLSNแอดเดรสLBAจึงเหมือนกันตราบใดที่ขนาดเซกเตอร์เชิงตรรกะของวอลุ่มเท่ากับขนาดเซกเตอร์ทางกายภาพของสื่อที่อยู่เบื้องหลัง ภายใต้เงื่อนไขเหล่านี้ การแปลงระหว่างCHSแอดเดรส จึงทำได้ง่าย LSNsเช่นกัน:

LSN=SPT×(HN+(NOS×TN))+SN−1โดยที่เซกเตอร์ต่อแทร็กSPTจะถูกจัดเก็บไว้ที่ออฟเซ็ต0x018และจำนวนด้านจะถูกจัดเก็บไว้ที่ออฟเซ็ต0x01Aหมายเลขแทร็กหมายเลขหัวและหมายเลขเซกเตอร์สอดคล้องกับCylinder-head-sector : สูตรนี้ให้การแปลง CHS เป็น LBA ที่ทราบแล้วNOSTNHNSN

โครงสร้างเพิ่มเติมที่ใช้โดย FAT12 และ FAT16 ตั้งแต่ OS/2 1.0 และ DOS 4.0 หรือที่รู้จักกันในชื่อExtended BIOS Parameter Block (EBPB) (ไบต์ที่อยู่ต่ำกว่าตำแหน่งออฟเซ็ตเซกเตอร์0x024เหมือนกับ BPB ของ DOS 3.31):

โดยพื้นฐานแล้ว FAT32 จะแทรก 28 ไบต์ลงใน EBPB ตามด้วย ไบต์ EBPB ที่เหลืออีก 26 ไบต์ (หรือบางครั้งเพียง 7 ไบต์) ดังที่แสดงไว้ข้างต้นสำหรับ FAT12 และ FAT16 ระบบปฏิบัติการของ Microsoft และ IBM จะกำหนดประเภทของระบบไฟล์ FAT ที่ใช้ในวอลุ่มโดยพิจารณาจากจำนวนคลัสเตอร์เท่านั้น ไม่ใช่จากรูปแบบ BPB ที่ใช้หรือประเภทของระบบไฟล์ที่ระบุ กล่าวคือ ในทางเทคนิคแล้ว เป็นไปได้ที่จะใช้ "FAT32 EBPB" สำหรับวอลุ่ม FAT12 และ FAT16 เช่นเดียวกับ DOS 4.0 EBPB สำหรับวอลุ่ม FAT32 ขนาดเล็ก เนื่องจากพบว่าระบบปฏิบัติการ Windows สร้างวอลุ่มดังกล่าวภายใต้เงื่อนไขที่แปลกประหลาดบางประการ^{[ nb 7 ]}ระบบปฏิบัติการจึงควรเตรียมพร้อมที่จะรับมือกับรูปแบบไฮบริดเหล่านี้

ระบบปฏิบัติการ DOS เวอร์ชันก่อน 3.2 อาศัยไบต์ตัวอธิบายสื่อใน BPB หรือ ไบต์ FAT IDในคลัสเตอร์ 0 ของ FAT ตัวแรกทั้งหมดหรือบางส่วน เพื่อกำหนดรูปแบบดิสก์ FAT12 แม้ว่าจะมี BPB อยู่ก็ตาม โดยขึ้นอยู่กับ FAT ID ที่พบและประเภทของไดรฟ์ที่ตรวจพบ ระบบจะใช้ต้นแบบ BPB ต่อไปนี้โดยค่าเริ่มต้น แทนที่จะใช้ค่าที่จัดเก็บไว้จริงใน BPB ^{[ nb 1 ]}

เดิมที FAT ID ถูกออกแบบมาให้เป็นแฟล็กบิตที่มีบิตทั้งหมดตั้งค่าไว้ ยกเว้นบิตที่ 2 ที่ถูกล้างเพื่อระบุรูปแบบ 80 แทร็ก (เทียบกับ 40 แทร็ก) บิตที่ 1 ที่ถูกล้างเพื่อระบุรูปแบบ 9 เซกเตอร์ (เทียบกับ 8 เซกเตอร์) และบิตที่ 0 ที่ถูกล้างเพื่อระบุรูปแบบด้านเดียว (เทียบกับสองด้าน) ^{[ 7 ]}แต่รูปแบบนี้ไม่ได้ถูกนำไปใช้โดย OEM ทุกรายและกลายเป็นสิ่งล้าสมัยเมื่อมีการนำฮาร์ดดิสก์และรูปแบบความหนาแน่นสูงมาใช้ นอกจากนี้ รูปแบบ 8 นิ้วต่างๆ ที่รองรับโดย86-DOSและ MS-DOS ก็ไม่ตรงกับรูปแบบนี้

Microsoft แนะนำให้แยกแยะความแตกต่างระหว่างรูปแบบ 8 นิ้วสองแบบสำหรับ FAT ID 0xFEโดยลองอ่านเครื่องหมายที่อยู่ความหนาแน่นเดียว หากเกิดข้อผิดพลาด สื่อจะต้องเป็นความหนาแน่นสองเท่า^{[ 23 ]}

ตารางนี้ไม่ได้แสดงรายการ รูปแบบฟลอปปี้ดิสก์ FAT12ขนาด 8 นิ้วและ 5.25 นิ้วที่ไม่เข้ากันจำนวนหนึ่ง ซึ่งรองรับโดย 86-DOS ซึ่งแตกต่างกันทั้งในขนาดของรายการไดเร็กทอรี (16 ไบต์เทียบกับ 32 ไบต์) หรือในขอบเขตของพื้นที่เซกเตอร์ที่สงวนไว้ (หลายแทร็กทั้งหมดเทียบกับเซกเตอร์เชิงตรรกะเพียงหนึ่งเดียว)

การใช้งานรูปแบบ FAT12 ด้านเดียวขนาด 315 KB ที่ใช้ในMS-DOSสำหรับApricot PCและF1e ^{[ 34 ]}มีเค้าโครงเซกเตอร์บูตที่แตกต่างกัน เพื่อรองรับ BIOS ที่ไม่เข้ากันกับ IBM ของคอมพิวเตอร์เครื่องนั้น คำสั่งกระโดดและชื่อ OEM ถูกละเว้น และพารามิเตอร์ MS-DOS BPB (ออฟเซ็ต0x00B - 0x017ในเซกเตอร์บูตมาตรฐาน) อยู่ที่ออฟเซ็ต0x050 Portable , F1 , PC duoและXi FDรองรับรูปแบบ FAT12 สองด้านขนาด 720 KB ที่ไม่เป็นมาตรฐานแทน[ ^{34 ] ความ}แตกต่างในเค้าโครงเซกเตอร์บูตและรหัสสื่อทำให้รูปแบบเหล่านี้ไม่เข้ากันกับระบบปฏิบัติการอื่นๆ มากมาย พารามิเตอร์เรขาคณิตสำหรับรูปแบบเหล่านี้คือ:

• 315 KB: ไบต์ต่อเซกเตอร์เชิงตรรกะ: 512 ไบต์, เซกเตอร์เชิงตรรกะต่อคลัสเตอร์: 1, เซกเตอร์เชิงตรรกะที่สงวนไว้: 1, จำนวน FAT: 2, รายการไดเร็กทอรีรูท: 128, เซกเตอร์เชิงตรรกะทั้งหมด: 630, รหัส FAT: 0xFC , เซกเตอร์เชิงตรรกะต่อ FAT: 2, เซกเตอร์ทางกายภาพต่อแทร็ก: 9, จำนวนหัว: 1. ^{[ 34 ] [ 35 ]}
• 720 KB: ไบต์ต่อเซกเตอร์เชิงตรรกะ: 512 ไบต์, เซกเตอร์เชิงตรรกะต่อคลัสเตอร์: 2, เซกเตอร์เชิงตรรกะที่สงวนไว้: 1, จำนวน FAT: 2, รายการไดเร็กทอรีรูท: 176, เซกเตอร์เชิงตรรกะทั้งหมด: 1440, รหัส FAT: 0xFE , เซกเตอร์เชิงตรรกะต่อ FAT: 3, เซกเตอร์ทางกายภาพต่อแทร็ก: 9, จำนวนหัว: 2. ^{[ 34 ]}

เวอร์ชันต่อมาของApricot MS-DOSมีความสามารถในการอ่านและเขียนดิสก์ที่มีเซกเตอร์บูตมาตรฐาน นอกเหนือจากดิสก์ที่มีเซกเตอร์บูตของ Apricot รูปแบบเหล่านี้ยังได้รับการสนับสนุนโดยDOS Plus 2.1e/g สำหรับซีรี่ส์ Apricot ACT ด้วย

การดัดแปลง DOS Plus สำหรับBBC Master 512รองรับรูปแบบ FAT12 สองรูปแบบบนไดรฟ์ 5.25 นิ้ว 80 แทร็ก สองด้าน ความหนาแน่นสองเท่า ซึ่งไม่ได้ใช้เซกเตอร์บูตแบบดั้งเดิมเลย ดิสก์ข้อมูล 800 KB ละเว้นเซกเตอร์บูตและเริ่มต้นด้วยสำเนา FAT เพียงชุดเดียว^{[ 35 ]}ไบต์แรกของ FAT ที่ย้ายตำแหน่งในเซกเตอร์ตรรกะ 0 ถูกใช้เพื่อกำหนดความจุของดิสก์ ดิสก์บูต 640 KB เริ่มต้นด้วย ระบบไฟล์ ADFS ขนาดเล็ก ที่มีบูตโหลดเดอร์ ตามด้วย FAT เพียงชุดเดียว^{[ 35 ] [ 36 ]}นอกจากนี้ รูปแบบ 640 KB ยังแตกต่างกันโดยใช้หมายเลขเซกเตอร์ CHS ทางกายภาพที่เริ่มต้นด้วย 0 (ไม่ใช่ 1 อย่างที่ปกติใช้กัน) และเซกเตอร์ที่เพิ่มขึ้นตามลำดับ เซกเตอร์-แทร็ก-หัว (ไม่ใช่ เซกเตอร์-หัว-แทร็ก อย่างที่ปกติใช้กัน) ^{[ 36 ]} FAT เริ่มต้นที่จุดเริ่มต้นของแทร็กถัดไป ความแตกต่างเหล่านี้ทำให้ระบบปฏิบัติการอื่นไม่สามารถจดจำรูปแบบเหล่านี้ได้ พารามิเตอร์ทางเรขาคณิตสำหรับรูปแบบเหล่านี้มีดังนี้:

• 800 KB: ไบต์ต่อเซกเตอร์เชิงตรรกะ: 1024 ไบต์, เซกเตอร์เชิงตรรกะต่อคลัสเตอร์: 1, เซกเตอร์เชิงตรรกะที่สงวนไว้: 0, จำนวน FAT: 1, รายการไดเร็กทอรีรูท: 192, เซกเตอร์เชิงตรรกะทั้งหมด: 800, รหัส FAT: 0xFD , เซกเตอร์เชิงตรรกะต่อ FAT: 2, เซกเตอร์ทางกายภาพต่อแทร็ก: 5, จำนวนหัว: 2 ^{[ 35 ] [ 36 ]}
• 640 KB: ไบต์ต่อเซกเตอร์เชิงตรรกะ: 256 ไบต์, เซกเตอร์เชิงตรรกะต่อคลัสเตอร์: 8, เซกเตอร์เชิงตรรกะที่สงวนไว้: 16, จำนวน FAT: 1, รายการไดเร็กทอรีรูท: 112, เซกเตอร์เชิงตรรกะทั้งหมด: 2560, รหัส FAT: 0xFF , เซกเตอร์เชิงตรรกะต่อ FAT: 2, เซกเตอร์ทางกายภาพต่อแทร็ก: 16, จำนวนหัว: 2. ^{[ 35 ] [ 36 ]}

DOS Plus สำหรับ Master 512 ยังสามารถเข้าถึงดิสก์พีซีมาตรฐานที่ฟอร์แมตไว้ที่180 KBหรือ360 KB ได้ โดยใช้ไบต์แรกของ FAT ในเซกเตอร์ตรรกะที่ 1 เพื่อกำหนดความจุ

ไดร์ฟ DEC Rainbow 100 (ทุกรุ่น) รองรับฟอร์แมต FAT12 เพียงรูปแบบเดียว บนไดร์ฟ 5.25 นิ้ว แบบ 80 แทร็ก ด้านเดียว ความหนาแน่นสี่เท่า สองแทร็กแรกสงวนไว้สำหรับบูตโหลดเดอร์ แต่ไม่มี MBR หรือ BPB (MS-DOS ใช้ BPB แบบคงที่ในหน่วยความจำแทน) เซกเตอร์บูต (แทร็ก 0 ด้าน 0 เซกเตอร์ 1) เป็นโค้ด Z80 ที่ขึ้นต้นด้วย DI 0xF3บูตสแตรป 8088 ถูกโหลดโดย Z80 แทร็ก 1 ด้าน 0 เซกเตอร์ 2 เริ่มต้นด้วยไบต์ Media/FAT ID 0xFAดิสก์ที่ยังไม่ได้ฟอร์แมตจะใช้0xE5แทน ระบบไฟล์เริ่มต้นที่แทร็ก 2 ด้าน 0 เซกเตอร์ 1 มีสำเนา FAT 2 ชุด และ 96 รายการในไดเร็กทอรีรูท นอกจากนี้ยังมีการแมปแทร็กทางกายภาพไปยังตรรกะเพื่อให้เกิดการสลับเซกเตอร์แบบ 2:1 ดิสก์ได้รับการฟอร์แมตด้วย ภาคกายภาพเรียงลำดับหมายเลข 1 ถึง 10 บนแต่ละแทร็กหลังจากแทร็กที่สงวนไว้ แต่ภาคตรรกะตั้งแต่ 1 ถึง 10 ถูกจัดเก็บในภาคกายภาพ 1, 6, 2, 7, 3, 8, 4, 9, 5, 10 ^{[ 37 ]}

“FS Information Sector” ถูกนำมาใช้ใน FAT32 ^{[ 38 ]}เพื่อเร่งความเร็วในการเข้าถึงการดำเนินการบางอย่าง (โดยเฉพาะการรับจำนวนพื้นที่ว่าง) โดยจะอยู่ที่หมายเลขเซกเตอร์เชิงตรรกะที่ระบุไว้ในเรคอร์ดบูต FAT32 EBPB ที่ตำแหน่ง0x030 (โดยปกติจะเป็นเซกเตอร์เชิงตรรกะที่ 1 ทันทีหลังจากเรคอร์ดบูต)

ข้อมูลในเซกเตอร์นี้อาจล้าสมัยและไม่สะท้อนเนื้อหาสื่อปัจจุบัน เนื่องจากระบบปฏิบัติการบางระบบไม่ได้อัปเดตหรือใช้เซกเตอร์นี้ และถึงแม้จะใช้ เนื้อหาก็จะไม่ถูกต้องเมื่อถอดสื่อออกโดยไม่ได้ยกเลิกการเชื่อมต่อวอลุ่มอย่างถูกต้อง หรือหลังจากไฟฟ้าดับ ดังนั้น ระบบปฏิบัติการควรตรวจสอบบิตแฟล็กสถานะการปิดระบบเสริมของวอลุ่มที่อยู่ในรายการ FAT ของคลัสเตอร์ 1หรือ FAT32 EBPB ที่ออฟเซ็ต0x041 ก่อน และละเว้นข้อมูลที่จัดเก็บในเซกเตอร์ข้อมูล FS หากบิตแฟล็กเหล่านี้ระบุว่าวอลุ่มไม่ได้ถูกยกเลิกการเชื่อมต่ออย่างถูกต้องก่อนหน้านี้ การดำเนินการนี้ไม่ก่อให้เกิดปัญหาใด ๆ นอกเหนือจากอาจทำให้ความเร็วในการสอบถามพื้นที่ว่างครั้งแรกหรือการจัดสรรคลัสเตอร์ข้อมูลลดลง โปรดดูที่หัวข้อ การแตกกระจายของข้อมูล (fragmentation )

หากเซกเตอร์นี้มีอยู่ในวอลุ่ม FAT32 ขนาดเซกเตอร์เชิงตรรกะ ขั้นต่ำที่อนุญาต คือ 512 ไบต์ ในขณะที่ถ้าไม่มีเซกเตอร์นี้จะเป็น 128 ไบต์ การใช้งาน FAT32 บางอย่างรองรับการเปลี่ยนแปลงเล็กน้อยจากข้อกำหนดของ Microsoft โดยทำให้เซกเตอร์ข้อมูล FS เป็นตัวเลือกโดยการระบุค่า0xFFFF ^{[ 19 ]} (หรือ0x0000 ) ในรายการ ที่ ออฟเซ็ต0x030

พื้นที่ข้อมูลของวอลุ่มจะถูกแบ่งออกเป็นคลัสเตอร์ ที่มีขนาดเท่ากัน ซึ่งเป็นบล็อก ^ขนาดเล็กของพื้นที่ต่อเนื่องกัน ขนาดของคลัสเตอร์จะแตกต่างกันไปขึ้นอยู่กับประเภทของระบบไฟล์ FAT ที่ใช้และขนาดของไดรฟ์ โดยทั่วไปขนาดของคลัสเตอร์จะมีตั้งแต่ 2 ถึง32 KiB ^{[ 39} ]

แต่ละไฟล์อาจใช้พื้นที่ในคลัสเตอร์หนึ่งคลัสเตอร์หรือมากกว่านั้น ขึ้นอยู่กับขนาดของไฟล์ ดังนั้น ไฟล์จึงถูกแสดงใน FAT ด้วยรายการเชื่อมโยงแบบเดี่ยว (singly linked list ) FAT ประกอบด้วยรายการที่มีความยาว 12, 16 หรือ 32 บิต ขึ้นอยู่กับว่าเป็น FAT12, FAT16 หรือ FAT32 รายการที่ต่อเนื่องกันจะสอดคล้องกับคลัสเตอร์ที่ต่อเนื่องกัน และค่าของรายการนั้นเป็นลิงก์ที่บอกว่าคลัสเตอร์ถัดไปในไฟล์นั้นคืออะไร การดูที่รายการที่สอดคล้องกับคลัสเตอร์นั้นจะบอกว่าคลัสเตอร์ถัดไปอยู่ที่ไหน และเป็นเช่นนี้ไปเรื่อยๆ จนกว่าจะมีรายการที่ระบุว่าสอดคล้องกับคลัสเตอร์สุดท้ายในห่วงโซ่คลัสเตอร์ที่เก็บไฟล์นั้น คลัสเตอร์ไม่จำเป็นต้องอยู่ติดกันบนพื้นผิวของดิสก์ แต่ส่วนใหญ่จะกระจายอยู่ทั่วพื้นที่ข้อมูล (Data Region)

แต่ละเวอร์ชันของระบบไฟล์ FAT ใช้ขนาดที่แตกต่างกันสำหรับรายการ FAT ตัวเลขที่เล็กกว่าจะทำให้ไฟล์ FAT มีขนาดเล็กลง แต่จะสิ้นเปลืองพื้นที่ในพาร์ติชันขนาดใหญ่เนื่องจากต้องจัดสรรเป็นกลุ่มขนาดใหญ่

ระบบ ไฟล์ FAT12ใช้ 12 บิตต่อรายการ FAT ดังนั้นสองรายการจึงใช้พื้นที่ 3 ไบต์ ระบบนี้เป็นแบบlittle-endian อย่างสม่ำเสมอ : หากพิจารณาสามไบต์นั้นเป็นตัวเลข 24 บิตแบบ little-endian หนึ่งตัว บิตที่มีค่าต่ำที่สุด 12 บิตจะแสดงถึงรายการแรก (เช่น คลัสเตอร์ 0) และบิตที่มีค่าสูงที่สุด 12 บิตจะแสดงถึงรายการที่สอง (เช่น คลัสเตอร์ 1) กล่าวอีกนัยหนึ่งคือ บิตแปดบิตล่างของคลัสเตอร์แรกในแถวจะถูกเก็บไว้ในไบต์แรก บิตสี่บิตบนจะถูกเก็บไว้ใน nibble ล่างของไบต์ที่สอง ในขณะที่บิตสี่บิตล่างของคลัสเตอร์ถัดไปในแถวจะถูกเก็บไว้ใน nibble บนของไบต์ที่สอง และบิตแปดบิตบนจะถูกเก็บไว้ในไบต์ที่สาม

The FAT16 file system uses 16 bits per FAT entry, thus one entry spans two bytes in little-endian byte order:

The FAT32 file system uses 32 bits per FAT entry, thus one entry spans four bytes in little-endian byte order. The four top bits of each entry are reserved for other purposes; they are cleared during formatting and should not be changed otherwise. They must be masked off before interpreting the entry as 28-bit cluster address.

The File Allocation Table (FAT) is a contiguous number of sectors immediately following the area of reserved sectors. It represents a list of entries that map to each cluster on the volume. Each entry records one of four things:

• the cluster number of the next cluster in a chain
• a special end of cluster-chain (EOC) entry that indicates the end of a chain
• a special entry to mark a bad cluster
• a zero to note that the cluster is unused

For very early versions of DOS to recognize the file system, the system must have been booted from the volume or the volume's FAT must start with the volume's second sector (logical sector 1 with physical CHS address 0/0/2 or LBA address 1), that is, immediately following the boot sector. Operating systems assume this hard-wired location of the FAT in order to find the FAT ID in the FAT's cluster 0 entry on DOS 1.0-1.1 FAT diskettes, where no valid BPB is found.

The first two entries in a FAT store special values:

รายการแรก (คลัสเตอร์ 0 ใน FAT) เก็บค่า FAT ID ตั้งแต่MS-DOS 1.20และPC DOS 1.1 (ค่าที่อนุญาตคือ0xF0 - 0xFFโดย สงวน 0xF1 - 0xF7 ) ในบิตที่ 7-0 ซึ่งจะถูกคัดลอกไปยัง BPB ของบูตเซกเตอร์ที่ออฟเซ็ต0x015ตั้งแต่ DOS 2.0 บิตที่เหลืออีก 4 บิต (ถ้าเป็น FAT12), 8 บิต (ถ้าเป็น FAT16) หรือ 20 บิต (ถ้าเป็น FAT32 โดย 4 บิต MSB เป็นศูนย์) ของรายการนี้จะเป็น 1 เสมอ ค่าเหล่านี้ถูกจัดเรียงเพื่อให้รายการนี้ทำหน้าที่เป็นเครื่องหมาย "ดักจับทั้งหมด" สำหรับจุดสิ้นสุดของห่วงโซ่สำหรับคลัสเตอร์ข้อมูลทั้งหมดที่มีค่าเป็นศูนย์ นอกจากนี้ สำหรับ FAT ID อื่นๆ นอกเหนือจาก0xFF (และ0x00 ) ก็สามารถกำหนดลำดับนิบเบิลและไบต์ที่ถูกต้องที่จะใช้โดยไดรเวอร์ระบบไฟล์ได้ อย่างไรก็ตาม ระบบไฟล์ FAT ใช้ การแสดงผลแบบ little-endianเท่านั้น และไม่มีการใช้งานรูปแบบใดๆ ที่ใช้ ค่า big-endianแทน86-DOS 0.42จนถึงMS-DOS 1.14ใช้โปรไฟล์ไดรฟ์แบบตายตัวแทน FAT ID แต่ใช้ไบต์นี้เพื่อแยกความแตกต่างระหว่างสื่อที่ฟอร์แมตด้วยรายการไดเร็กทอรี 32 ไบต์หรือ 16 ไบต์ ตามที่ใช้ก่อน 86-DOS 0.42

รายการที่สอง (คลัสเตอร์ 1 ในระบบไฟล์ FAT) โดยปกติจะเก็บเครื่องหมายสิ้นสุดของห่วงโซ่คลัสเตอร์ตามที่ตัวจัดรูปแบบใช้ แต่โดยทั่วไปแล้วจะเก็บค่า0xFFF / 0xFFFF / 0x0FFFFFFF เสมอ กล่าวคือ ยกเว้นบิตที่ 31-28 บนไดรฟ์ FAT32 บิตเหล่านี้มักจะถูกตั้งค่าไว้เสมอ อย่างไรก็ตาม ระบบปฏิบัติการของ Microsoft บางระบบจะตั้งค่าบิตเหล่านี้หากไดรฟ์นั้นไม่ใช่ไดรฟ์ที่เก็บระบบปฏิบัติการที่กำลังทำงานอยู่ (กล่าวคือ ใช้0xFFFFFFFFแทน0x0FFFFFFFในที่นี้) ^{[ 40 ]} (เมื่อใช้ร่วมกับเครื่องหมายสิ้นสุดโซ่ทางเลือก บิตต่ำสุด 2-0 สามารถเป็นศูนย์ได้สำหรับเครื่องหมายสิ้นสุดโซ่ที่อนุญาตต่ำสุด0xFF8 / 0xFFF8 / 0x?FFFFFF8 ; ควรสงวนบิต 3 ไว้เช่นกัน เนื่องจากคลัสเตอร์0xFF0 / 0xFFF0 / 0x?FFFFFF0และสูงกว่านั้นถูกสงวนไว้อย่างเป็นทางการ ระบบปฏิบัติการบางระบบอาจไม่สามารถเมานต์วอลุ่มบางส่วนได้หากบิตเหล่านี้ไม่ได้ตั้งค่า ดังนั้นเครื่องหมายสิ้นสุดโซ่เริ่มต้นจึงไม่ควรเปลี่ยนแปลง) สำหรับ DOS 1 และ 2 รายการนี้ได้รับการบันทึกไว้ว่าสงวนไว้สำหรับการใช้งานในอนาคต

ตั้งแต่ DOS 7.1 บิตที่มีนัยสำคัญที่สุดสองบิตของรายการคลัสเตอร์นี้อาจเก็บบิตแฟล็กเสริมสองตัวที่แสดงสถานะวอลุ่มปัจจุบันบน FAT16 และ FAT32 แต่ไม่ใช่บนวอลุ่ม FAT12 บิตแฟล็กเหล่านี้ไม่ได้รับการสนับสนุนโดยระบบปฏิบัติการทั้งหมด แต่ระบบปฏิบัติการที่รองรับคุณสมบัตินี้จะตั้งค่าบิตเหล่านี้เมื่อปิดระบบและล้างบิตที่มีนัยสำคัญที่สุดเมื่อเริ่มต้นระบบ: หากบิต 15 (บน FAT16) หรือบิต 27 (บน FAT32) ^{[ 41 ]}ไม่ได้รับการตั้งค่าเมื่อทำการเมานต์วอลุ่ม แสดงว่าวอลุ่มไม่ได้ถูกยกเลิกการเมานต์อย่างถูกต้องก่อนปิดระบบหรือนำออก ดังนั้นจึงอยู่ในสถานะที่ไม่ทราบและอาจ "สกปรก" ^{[ 27 ]}บนวอลุ่ม FAT32 เซกเตอร์ข้อมูล FSอาจมีข้อมูลที่ล้าสมัย ดังนั้นจึงไม่ควรใช้ โดยทั่วไประบบปฏิบัติการจะเรียกใช้SCANDISKหรือCHKDSKในการเริ่มต้นระบบครั้งถัดไป^{[ nb 10 ] [ 41 ]} (แต่ไม่ใช่เมื่อเสียบสื่อแบบถอดได้) เพื่อให้แน่ใจและอาจสร้างความสมบูรณ์ของวอลุ่มขึ้นใหม่ หากบิตที่ 14 (บน FAT16) หรือบิตที่ 26 (บน FAT32) ^{[ 41 ]}ถูกล้าง ระบบปฏิบัติการจะพบข้อผิดพลาด I/O ของดิสก์เมื่อเริ่มต้นระบบ^{[ 41 ]}ซึ่งอาจเป็นสัญญาณบ่งชี้ถึงเซกเตอร์เสีย ระบบปฏิบัติการที่รับรู้ส่วนขยายนี้จะตีความสิ่งนี้ว่าเป็นคำแนะนำให้ทำการสแกนพื้นผิว ( SCANDISK ) ในการบูตครั้งถัดไป^{[ 27 ] [ 41 ]} (ชุดบิตแฟลกที่คล้ายกันมีอยู่ใน FAT12/FAT16 EBPB ที่ออฟเซ็ต0x1Aหรือ FAT32 EBPB ที่ออฟเซ็ต0x36ในขณะที่ไดรเวอร์ระบบไฟล์สามารถเข้าถึงรายการคลัสเตอร์ 1 ได้เมื่อติดตั้งวอลุ่มแล้ว รายการ EBPB จะพร้อมใช้งานแม้ว่าวอลุ่มจะยังไม่ได้ติดตั้ง ดังนั้นจึงใช้งานได้ง่ายกว่าโดยไดรเวอร์อุปกรณ์บล็อกดิสก์หรือเครื่องมือแบ่งพาร์ติชัน)

หากไม่ได้ตั้งค่าจำนวน FAT ใน BPB เป็น 2 รายการคลัสเตอร์ที่สองใน FAT แรก (คลัสเตอร์ 1) อาจสะท้อนสถานะของ วอลุ่ม TFATสำหรับระบบปฏิบัติการที่รองรับ TFAT หากรายการคลัสเตอร์ 1 ใน FAT นั้นมีค่าเป็น 0 อาจบ่งชี้ว่า FAT ที่สองแสดงถึงสถานะธุรกรรมที่ถูกต้องล่าสุดที่ทราบ และควรคัดลอกทับ FAT แรก ในขณะที่ FAT แรกควรคัดลอกทับ FAT ที่สองหากบิตทั้งหมดถูกตั้งค่า

การใช้งาน FAT12/FAT16 ที่ไม่เป็นไปตามมาตรฐานบางอย่างใช้รายการคลัสเตอร์ 1 เพื่อจัดเก็บคลัสเตอร์เริ่มต้นของไดเร็กทอรีรูทที่มีขนาดแปรผันได้ (โดยทั่วไปคือ 2 ^{[ 33 ]} ) ซึ่งอาจเกิดขึ้นเมื่อจำนวนรายการไดเร็กทอรีรูทใน BPB มีค่าเป็น 0 และไม่พบ FAT32 EBPB (ไม่มีลายเซ็น0x29หรือ0x28ที่ออฟเซ็ต0x042 ) ^{[ 20 ]}อย่างไรก็ตาม ส่วนขยายนี้ไม่ได้รับการสนับสนุนจากระบบปฏิบัติการหลัก^{[ 20 ]}เนื่องจากขัดแย้งกับการใช้งานอื่นๆ ที่เป็นไปได้ของรายการคลัสเตอร์ 1 ความขัดแย้งส่วนใหญ่สามารถตัดออกได้หากอนุญาตให้ใช้ส่วนขยายนี้เฉพาะกับ FAT12 ที่มีคลัสเตอร์น้อยกว่า0xFEFและวอลุ่ม FAT16 ที่มีคลัสเตอร์น้อยกว่า0x3FEFและ 2 FAT เท่านั้น

เนื่องจากรายการ FAT สองรายการแรกนี้จัดเก็บค่าพิเศษ จึงไม่มีคลัสเตอร์ข้อมูล 0 หรือ 1 คลัสเตอร์ข้อมูลแรก (หลังจากไดเร็กทอรีรากหากเป็น FAT12/FAT16) คือคลัสเตอร์ 2 ^{[ 33 ]}ซึ่งเป็นจุดเริ่มต้นของพื้นที่ข้อมูล

ค่าอินพุต FAT:

FAT32 uses 28 bits for cluster numbers. The remaining 4 bits in the 32-bit FAT entry are usually zero, but are reserved and should be left untouched. A standard conformant FAT32 file system driver or maintenance tool must not rely on the upper 4 bits to be zero and it must strip them off before evaluating the cluster number in order to cope with possible future expansions where these bits may be used for other purposes. They must not be cleared by the file system driver when allocating new clusters, but should be cleared during a reformat.

The root directory table in FAT12 and FAT16 file systems occupies the special Root Directory Region location.

Aside from the root directory table in FAT12 and FAT16 file systems, which occupies the special Root Directory Region location, all directory tables are stored in the data region. The actual number of entries in a directory stored in the data region can grow by adding another cluster to the chain in the FAT.

A directory table is a special type of file that represents a directory (also known as a folder). Since 86-DOS 0.42,^[46] each file or (since MS-DOS 1.40 and PC DOS 2.0) subdirectory stored within it is represented by a 32-byte entry in the table. Each entry records the name, extension, attributes (archive, directory, hidden, read-only, system and volume), the address of the first cluster of the file/directory's data, the size of the file/directory, and the date^[46] and (since PC DOS 1.1) also the time of last modification. Earlier versions of 86-DOS used 16-byte directory entries only, supporting no files larger than 16 MB and no time of last modification.^[46]

ระบบไฟล์ FAT เองไม่ได้กำหนดข้อจำกัดใดๆ เกี่ยวกับความลึกของโครงสร้างไดเร็กทอรีย่อย ตราบใดที่มีคลัสเตอร์ว่างให้จัดสรรไดเร็กทอรีย่อย อย่างไรก็ตาม โครงสร้างไดเร็กทอรีปัจจุบันภายใน (CDS) ภายใต้ MS-DOS/PC DOS จำกัดเส้นทางสัมบูรณ์ของไดเร็กทอรีไว้ที่ 66 อักขระ (รวมถึงตัวอักษรไดรฟ์ แต่ไม่รวมตัวคั่นไบต์ NUL) ^{[ 24 ] [ 25 ] [ 26 ]}จึงจำกัดความลึกสูงสุดที่รองรับของไดเร็กทอรีย่อยไว้ที่ 32 ไม่ว่าจะเกิดขึ้นก่อนก็ตาม Concurrent DOS, Multiuser DOS และ DR DOS 3.31 ถึง 6.0 (รวมถึงการอัปเดต 1992-11) ไม่ได้จัดเก็บเส้นทางสัมบูรณ์ไปยังไดเร็กทอรีการทำงานภายใน ดังนั้นจึงไม่แสดงข้อจำกัดนี้^{[ 47 ]}เช่นเดียวกันนี้ใช้กับ Atari GEMDOS แต่ Atari Desktop ไม่รองรับระดับไดเร็กทอรีย่อยมากกว่า 8 ระดับ แอปพลิเคชันส่วนใหญ่ที่รับรู้ถึงส่วนขยายนี้รองรับเส้นทางได้ถึงอย่างน้อย 127 ไบต์ FlexOS, 4680 OS และ 4690 OS รองรับความยาวได้ถึง 127 ไบต์เช่นกัน ทำให้สามารถมีความลึกได้ถึง 60 ระดับ^{[ 48 ]} PalmDOS, DR DOS 6.0 (ตั้งแต่ BDOS 7.1) และเวอร์ชันที่สูงกว่า, Novell DOS และ OpenDOS มี CDS ที่เข้ากันได้กับ MS-DOS ดังนั้นจึงมีข้อจำกัดความยาวเช่นเดียวกับ MS-DOS/PC DOS

แต่ละรายการสามารถนำหน้าด้วย "รายการปลอม" เพื่อรองรับชื่อไฟล์แบบยาว (LFN) ของ VFATได้ โปรดดูรายละเอียดเพิ่มเติมด้านล่าง

อักขระที่ถูกต้องสำหรับการตั้งชื่อไฟล์แบบสั้นในระบบ DOS มีดังต่อไปนี้:

• ตัวอักษรพิมพ์ใหญ่A–Z
• ตัวเลข0–9
• ช่องว่าง (ถึงแม้ว่าช่องว่างท้ายชื่อไฟล์หรือนามสกุลจะถือเป็นส่วนเติมเต็มและไม่ใช่ส่วนหนึ่งของชื่อไฟล์ก็ตาม และชื่อไฟล์ที่มีช่องว่างนั้นไม่สามารถใช้งานได้ง่ายบนบรรทัดคำสั่ง DOS ก่อน Windows 95 เนื่องจากขาดระบบการหลีกเลี่ยง ที่เหมาะสม ) ข้อยกเว้นอีกประการหนึ่งคือคำสั่งภายในMKDIR/ MDและRMDIR/ RDภายใต้ DR-DOS ซึ่งรับอาร์กิวเมนต์เดียวและอนุญาตให้ใส่ช่องว่างได้
• ! # $ % & ' ( ) - @ ^ _ ` { } ~
• ตัวละครหมายเลข 128–228
• ตัวละคร 230–255

ซึ่งไม่รวมอักขระ ASCIIต่อไปนี้:

• " * / : < > ? \ | ระบบ ปฏิบัติการ Windows/MS-DOS ไม่มีอักขระหลีก (escape character) สำหรับ เชลล์
• + , . ; = [ ]อนุญาตเฉพาะในชื่อไฟล์ที่ยาวเท่านั้น
• ตัวอักษรพิมพ์เล็กa– zจัดเก็บเป็นA– Z; อนุญาตให้ใช้ในชื่อไฟล์ที่ยาวได้
• อักขระควบคุม 0–31
• ตัวละคร 127 (DEL)

อักขระหมายเลข 229 ( 0xE5 ) ไม่ได้รับอนุญาตให้ใช้เป็นอักขระตัวแรกในชื่อไฟล์ใน DOS 1 และ 2 เนื่องจากถูกใช้เป็นเครื่องหมายระบุตำแหน่งว่าง มีการเพิ่มกรณีพิเศษเพื่อหลีกเลี่ยงข้อจำกัดนี้ใน DOS 3.0 และเวอร์ชันที่สูงกว่า

อักขระเพิ่มเติมต่อไปนี้สามารถใช้ได้บน GEMDOS ของ Atari แต่ควรหลีกเลี่ยงเพื่อความเข้ากันได้กับ MS-DOS/PC DOS:

• " + , ; < = > [ ] |

;ควรหลีกเลี่ยงการใช้เครื่องหมายเซมิโคลอน ( ) ในชื่อไฟล์ภายใต้ DR DOS 3.31 ขึ้นไป, PalmDOS, Novell DOS, OpenDOS, Concurrent DOS, Multiuser DOS, System Manager และ REAL/32 เนื่องจากอาจขัดแย้งกับไวยากรณ์ในการระบุรหัสผ่านไฟล์และไดเร็กทอรี: " ...\DIRSPEC.EXT;DIRPWD\FILESPEC.EXT;FILEPWD" ระบบปฏิบัติการจะตัดเครื่องหมายเซมิโคลอนออกหนึ่งตัว^{[ 47 ]} (และสองตัว—ตั้งแต่ DR-DOS 7.02) และรหัสผ่านที่รออยู่ออกจากชื่อไฟล์ก่อนที่จะจัดเก็บลงดิสก์ (ตัวประมวลผลคำสั่ง4DOSใช้เครื่องหมายเซมิโคลอนสำหรับรายการที่รวมอยู่และต้องใช้เครื่องหมายเซมิโคลอนสองตัวสำหรับไฟล์ที่ป้องกันด้วยรหัสผ่านที่มีคำสั่งใดๆ ที่รองรับไวด์การ์ด^{[ 47 ]} )

อักขระเครื่องหมาย @ ( @) ถูกใช้สำหรับรายการไฟล์โดย DR-DOS, PalmDOS, Novell DOS, OpenDOS และ Multiuser DOS, System Manager และคำสั่ง REAL/32 จำนวนมาก รวมถึง 4DOS ด้วย ดังนั้นบางครั้งอาจใช้งานในชื่อไฟล์ได้ยาก^{[ 47 ]}

ภายใต้ Multiuser DOS และ REAL/32 เครื่องหมายอัศเจรีย์ (!) ไม่ใช่อักขระชื่อไฟล์ที่ถูกต้อง เนื่องจากใช้เพื่อแยกคำสั่งหลายคำสั่งในบรรทัดคำสั่งเดียว^{[ 47 ]}

ในระบบปฏิบัติการ IBM 4680 OS และ 4690 OS ไม่อนุญาตให้ใช้ตัวอักษรต่อไปนี้ในชื่อไฟล์:

• ? * : . ; , [ ] ! + = < > " - / \ |

นอกจากนี้ ไม่อนุญาตให้ใช้ตัวอักษรพิเศษต่อไปนี้ในตัวอักษรตัวแรก ตัวที่สี่ ตัวที่ห้า และตัวที่แปดของชื่อไฟล์ เนื่องจากจะไปขัดแย้งกับชื่อไฟล์ของตัวประมวลผลคำสั่งโฮสต์ (HCP) และชื่อไฟล์สร้างตารางลำดับอินพุต:

• @ # ( ) { } $ &

ชื่อไฟล์ DOS ใช้ชุดอักขระ OEM ปัจจุบัน ซึ่งอาจส่งผลกระทบที่คาดไม่ถึงได้ หากอักขระที่จัดการในลักษณะหนึ่งสำหรับหน้ารหัสหนึ่ง ถูกตีความแตกต่างกันสำหรับหน้ารหัสอื่น (คำสั่ง DOS CHCP) ในแง่ของตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ การเรียงลำดับ หรือความถูกต้องในฐานะอักขระชื่อไฟล์

ก่อนที่ Microsoft จะเพิ่มการรองรับชื่อไฟล์ยาวและการประทับเวลาสร้าง/เข้าถึง ไบต์0x0C – 0x15ของรายการไดเร็กทอรีถูกใช้โดยระบบปฏิบัติการอื่นๆ เพื่อจัดเก็บข้อมูลเมตาเพิ่มเติม โดยเฉพาะอย่างยิ่งระบบปฏิบัติการในตระกูล Digital Research ที่จัดเก็บรหัสผ่านไฟล์ สิทธิ์การเข้าถึง รหัสเจ้าของ และข้อมูลการลบไฟล์ไว้ที่นั่น แม้ว่าส่วนขยายใหม่ๆ ของ Microsoft จะไม่เข้ากันได้กับส่วนขยายเหล่านี้โดยค่าเริ่มต้น แต่ส่วนใหญ่สามารถใช้งานร่วมกันได้ในระบบไฟล์ FAT ของบริษัทอื่น (อย่างน้อยก็ในไดรฟ์ FAT12 และ FAT16)

รายการไดเร็กทอรีขนาด 32 ไบต์ ทั้งในส่วนไดเร็กทอรีรากและในไดเร็กทอรีย่อย มีรูปแบบดังต่อไปนี้ (ดูเพิ่มเติมที่8.3 ชื่อไฟล์ ):

ระบบปฏิบัติการที่ใช้FlexOS เช่น IBM 4680 OSและIBM 4690 OSรองรับคุณลักษณะการแจกจ่ายเฉพาะที่จัดเก็บไว้ในบิตบางส่วนของพื้นที่ที่สงวนไว้ก่อนหน้านี้ในรายการไดเร็กทอรี: ^{[ 62 ]}

1. โลคอล: อย่าแจกจ่ายไฟล์ แต่ให้เก็บไว้ในคอนโทรลเลอร์โลคอลเท่านั้น^{[ nb 15 ]}
2. คัดลอกไฟล์เมื่อมีการอัปเดต: แจกจ่ายไฟล์ไปยังเซิร์ฟเวอร์เฉพาะเมื่อไฟล์มีการอัปเดตเท่านั้น
3. คัดลอกไฟล์เมื่อปิด: แจกจ่ายไฟล์ไปยังเซิร์ฟเวอร์เฉพาะเมื่อปิดไฟล์แล้วเท่านั้น
4. การอัปเดตไฟล์แบบรวม: แจกจ่ายไฟล์ไปยังคอนโทรลเลอร์ทั้งหมดเมื่อไฟล์ได้รับการอัปเดต
5. ไฟล์ผสมเมื่อปิด: กระจายไฟล์ไปยังตัวควบคุมทั้งหมดเมื่อปิดไฟล์^{[ 63 ]}

ส่วนขยายที่ไม่เข้ากันบางส่วนที่พบในระบบปฏิบัติการบางระบบ ได้แก่:

ระบบไฟล์ FAT ได้แก่ FAT12, FAT16, FAT16B และ FAT32 มีข้อจำกัดที่ชัดเจนโดยอิงจากจำนวนคลัสเตอร์และจำนวนเซกเตอร์ต่อคลัสเตอร์ (1, 2, 4, ..., 128) สำหรับค่าทั่วไปที่ 512 ไบต์ต่อเซกเตอร์:

FAT12 requirements : 3 sectors on each copy of FAT for every 1,024 clusters FAT16 requirements : 1 sector on each copy of FAT for every 256 clusters FAT32 requirements : 1 sector on each copy of FAT for every 128 clusters FAT12 range : 1 to 4,084 clusters : 1 to 12 sectors per copy of FAT FAT16 range : 4,085 to 65,524 clusters : 16 to 256 sectors per copy of FAT FAT32 range : 65,525 to 268,435,444 clusters : 512 to 2,097,152 sectors per copy of FAT FAT12 minimum : 1 sector per cluster × 1 clusters = 512 bytes (0.5 KiB) FAT16 minimum : 1 sector per cluster × 4,085 clusters = 2,091,520 bytes (2,042.5 KB) FAT32 minimum : 1 sector per cluster × 65,525 clusters = 33,548,800 bytes (32,762.5 KB) FAT12 maximum : 64 sectors per cluster × 4,084 clusters = 133,824,512 bytes (≈ 127 MB) [FAT12 maximum : 128 sectors per cluster × 4,084 clusters = 267,694,024 bytes (≈ 255 MB)] FAT16 maximum : 64 sectors per cluster × 65,524 clusters = 2,147,090,432 bytes (≈2,047 MB) [FAT16 maximum : 128 sectors per cluster × 65,524 clusters = 4,294,180,864 bytes (≈4,095 MB)] FAT32 maximum : 8 sectors per cluster × 268,435,444 clusters = 1,099,511,578,624 bytes (≈1,024 GB) FAT32 maximum : 16 sectors per cluster × 268,173,557 clusters = 2,196,877,778,944 bytes (≈2,046 GB) [FAT32 maximum : 32 sectors per cluster × 134,152,181 clusters = 2,197,949,333,504 bytes (≈2,047 GB)] [FAT32 maximum : 64 sectors per cluster × 67,092,469 clusters = 2,198,486,024,192 bytes (≈2,047 GB)] [FAT32 maximum : 128 sectors per cluster × 33,550,325 clusters = 2,198,754,099,200 bytes (≈2,047 GB)]

Legend: 268435444+3 is 0x0FFFFFF7, because FAT32 version 0 uses only 28 bits in the 32-bit cluster numbers, cluster numbers 0x0FFFFFF7 up to 0x0FFFFFFF flag bad clusters or the end of a file, cluster number 0 flags a free cluster, and cluster number 1 is not used.^[33] Likewise 65524+3 is 0xFFF7 for FAT16, and 4084+3 is 0xFF7 for FAT12. The number of sectors per cluster is a power of 2 fitting in a single byte, the smallest value is 1 (0x01), the biggest value is 128 (0x80). Lines in square brackets indicate the unusual cluster size 128, and for FAT32 the bigger than necessary cluster sizes 32 or 64.^[64]

Because each FAT32 entry occupies 32 bits (4 bytes) the maximal number of clusters (268435444) requires 2097152 FAT sectors for a sector size of 512 bytes. 2097152 is 0x200000, and storing this value needs more than two bytes. Therefore, FAT32 introduced a new 32-bit value in the FAT32 boot sector immediately following the 32-bit value for the total number of sectors introduced in the FAT16B variant.

The boot record extensions introduced with DOS 4.0 start with a magic 40 (0x28) or 41 (0x29). Typically FAT drivers look only at the number of clusters to distinguish FAT12, FAT16, and FAT32: the human readable strings identifying the FAT variant in the boot record are ignored, because they exist only for media formatted with DOS 4.0 or later.

Determining the number of directory entries per cluster is straightforward. Each entry occupies 32 bytes; this results in 16 entries per sector for a sector size of 512 bytes. The DOS 5 RMDIR/RD command removes the initial "." (this directory) and ".." (parent directory) entries in subdirectories directly, therefore sector size 32 on a RAM disk is possible for FAT12, but requires 2 or more sectors per cluster. A FAT12 boot sector without the DOS 4 extensions needs 29 bytes before the first unnecessary FAT16B 32-bit number of hidden sectors, this leaves three bytes for the (on a RAM disk unused) boot code and the magic 0x55 0xAA at the end of all boot sectors. On Windows NT the smallest supported sector size is 128.

On Windows NT operating systems the FORMAT command options /A:128K and /A:256K correspond to the maximal cluster size 0x80 (128) with a sector size 1024 and 2048, respectively. For the common sector size 512 /A:64K yields 128 sectors per cluster.

Both editions of each ECMA-107^[24] and ISO/IEC 9293^[25][26] specify a Max Cluster NumberMAX determined by the formula MAX=1+trunc((TS-SSA)/SC), and reserve cluster numbers MAX+1 up to 4086 (0xFF6, FAT12) and later 65526 (0xFFF6, FAT16) for future standardization.

Microsoft's EFI FAT32 specification^[4] states that any FAT file system with less than 4085 clusters is FAT12, else any FAT file system with less than 65,525 clusters is FAT16, and otherwise it is FAT32. The entry for cluster 0 at the beginning of the FAT must be identical to the media descriptor byte found in the BPB, whereas the entry for cluster 1 reflects the end-of-chain value used by the formatter for cluster chains (0xFFF, 0xFFFF or 0x0FFFFFFF). The entries for cluster numbers 0 and 1 end at a byte boundary even for FAT12, e.g., 0xF9FFFF for media descriptor 0xF9.

The first data cluster is 2,^[33] and consequently the last cluster MAX gets number MAX+1. This results in data cluster numbers 2...4085 (0xFF5) for FAT12, 2...65525 (0xFFF5) for FAT16, and 2...268435445 (0x0FFFFFF5) for FAT32.

The only available values reserved for future standardization are therefore 0xFF6 (FAT12) and 0xFFF6 (FAT16). As noted below "less than 4085" is also used for Linux implementations,^[44] or as Microsoft's FAT specification puts it:^[4]

...when it says <, it does not mean <=. Note also that the numbers are correct. The first number for FAT12 is 4085; the second number for FAT16 is 65525. These numbers and the "<" signs are not wrong."

The FAT file system does not contain built-in mechanisms which prevent newly written files from becoming scattered across the partition.^[65] On volumes where files are created and deleted frequently or their lengths often changed, the medium will become increasingly fragmented over time.

While the design of the FAT file system does not cause any organizational overhead in disk structures or reduce the amount of free storage space with increased amounts of fragmentation, as it occurs with external fragmentation, the time required to read and write fragmented files will increase as the operating system will have to follow the cluster chains in the FAT (with parts having to be loaded into memory first in particular on large volumes) and read the corresponding data physically scattered over the whole medium reducing chances for the low-level block device driver to perform multi-sector disk I/O or initiate larger DMA transfers, thereby effectively increasing I/O protocol overhead as well as arm movement and head settle times inside the disk drive. Also, file operations will become slower with growing fragmentation as it takes increasingly longer for the operating system to find files or free clusters.

Other file systems, e.g., HPFS or exFAT, use free space bitmaps that indicate used and available clusters, which could then be quickly looked up in order to find free contiguous areas. Another solution is the linkage of all free clusters into one or more lists (as is done in Unix file systems). Instead, the FAT has to be scanned as an array to find free clusters, which can lead to performance penalties with large disks.

In fact, seeking for files in large subdirectories or computing the free disk space on FAT volumes is one of the most resource intensive operations, as it requires reading the directory tables or even the entire FAT linearly. Since the total amount of clusters and the size of their entries in the FAT was still small on FAT12 and FAT16 volumes, this could still be tolerated on FAT12 and FAT16 volumes most of the time, considering that the introduction of more sophisticated disk structures would have also increased the complexity and memory footprint of real-mode operating systems with their minimum total memory requirements of 128 KB or less (such as with DOS) for which FAT has been designed and optimized originally.

With the introduction of FAT32, long seek and scan times became more apparent, particularly on very large volumes. A possible justification suggested by Microsoft's Raymond Chen for limiting the maximum size of FAT32 partitions created on Windows was the time required to perform a "DIR" operation, which always displays the free disk space as the last line.^[66] Displaying this line took longer and longer as the number of clusters increased. FAT32 therefore introduced a special file system information sector where the previously computed amount of free space is preserved over power cycles, so that the free space counter needs to be recalculated only when a removable FAT32 formatted medium gets ejected without first unmounting it or if the system is switched off without properly shutting down the operating system, a problem mostly visible with pre-ATX-style PCs, on plain DOS systems and some battery-powered consumer products.

With the huge cluster sizes (16 KB, 32 KB, 64 KB) forced by larger FAT partitions, internal fragmentation in form of disk space waste by file slack due to cluster overhang (as files are rarely exact multiples of cluster size) starts to be a problem as well, especially when there are a great many small files.

Various optimizations and tweaks to the implementation of FAT file system drivers, block device drivers and disk tools have been devised to overcome most of the performance bottlenecks in the file system's inherent design without having to change the layout of the on-disk structures.^[67][68] They can be divided into on-line and off-line methods and work by trying to avoid fragmentation in the file system in the first place, deploying methods to better cope with existing fragmentation, and by reordering and optimizing the on-disk structures. With optimizations in place, the performance on FAT volumes can often reach that of more sophisticated file systems in practical scenarios, while at the same time retaining the advantage of being accessible even on very small or old systems.

DOS 3.0 and higher will not immediately reuse disk space of deleted files for new allocations but instead seek for previously unused space before starting to use disk space of previously deleted files as well. This not only helps to maintain the integrity of deleted files for as long as possible but also speeds up file allocations and avoids fragmentation, since never before allocated disk space is always unfragmented. DOS accomplishes this by keeping a pointer to the last allocated cluster on each mounted volume in memory and starts searching for free space from this location upwards instead of at the beginning of the FAT, as it was still done by DOS 2.x.^[13] If the end of the FAT is reached, it would wrap around to continue the search at the beginning of the FAT until either free space has been found or the original position has been reached again without having found free space.^[13] These pointers are initialized to point to the start of the FATs after bootup,^[13] but on FAT32 volumes, DOS 7.1 and higher will attempt to retrieve the last position from the FS Information Sector. This mechanism is defeated, however, if an application often deletes and recreates temporary files as the operating system would then try to maintain the integrity of void data effectively causing more fragmentation in the end.^[13] In some DOS versions, the usage of a special API function to create temporary files can be used to avoid this problem.

Additionally, directory entries of deleted files will be marked 0xE5 since DOS 3.0.^[42] DOS 5.0 and higher will start to reuse these entries only when previously unused directory entries have been used up in the table and the system would otherwise have to expand the table itself.^[6]

Since DOS 3.3 the operating system provides means to improve the performance of file operations with FASTOPEN by keeping track of the position of recently opened files or directories in various forms of lists (MS-DOS/PC DOS) or hash tables (DR-DOS), which can reduce file seek and open times significantly. Before DOS 5.0 special care must be taken when using such mechanisms in conjunction with disk defragmentation software bypassing the file system or disk drivers.

Windows NT will allocate disk space to files on FAT in advance, selecting large contiguous areas, but in case of a failure, files which were being appended will appear larger than they were ever written into, with a lot of random data at the end.

Other high-level mechanisms may read in and process larger parts or the complete FAT on startup or on demand when needed and dynamically build up in-memory tree representations of the volume's file structures different from the on-disk structures.^[67][68] This may, on volumes with many free clusters, occupy even less memory than an image of the FAT itself. In particular on highly fragmented or filled volumes, seeks become much faster than with linear scans over the actual FAT, even if an image of the FAT would be stored in memory. Also, operating on the logically high level of files and cluster-chains instead of on sector or track level, it becomes possible to avoid some degree of file fragmentation in the first place or to carry out local file defragmentation and reordering of directory entries based on their names or access patterns in the background.

Some of the perceived problems with fragmentation of FAT file systems also result from performance limitations of the underlying block device drivers, which becomes more visible the lesser memory is available for sector buffering and track blocking/deblocking:

While the single-tasking DOS had provisions for multi-sector reads and track blocking/deblocking, the operating system and the traditional PC hard disk architecture (only one outstanding input/output request at a time and no DMA transfers) originally did not contain mechanisms which could alleviate fragmentation by asynchronously prefetching next data while the application was processing the previous chunks. Such features became available later. Later DOS versions also provided built-in support for look-ahead sector buffering and came with dynamically loadable disk caching programs working on physical or logical sector level, often utilizing EMS or XMS memory and sometimes providing adaptive caching strategies or even run in protected mode through DPMS or Cloaking to increase performance by gaining direct access to the cached data in linear memory rather than through conventional DOS APIs.

Write-behind caching was often not enabled by default with Microsoft software (if present) given the problem of data loss in case of a power failure or crash, made easier by the lack of hardware protection between applications and the system.

VFAT Long File Names (LFNs) are stored on a FAT file system using a trick: adding additional entries into the directory before the normal file entry. The additional entries are marked with the Volume Label, System, Hidden, and Read Only attributes (yielding 0x0F), which is a combination that is not expected in the MS-DOS environment, and therefore ignored by MS-DOS programs and third-party utilities. Notably, a directory containing only volume labels is considered as empty and is allowed to be deleted; such a situation appears if files created with long names are deleted from plain DOS. This method is very similar to the DELWATCH method to utilize the volume attribute to hide pending delete files for possible future undeletion since DR DOS 6.0 (1991) and higher. It is also similar to a method publicly discussed to store long filenames on Ataris and under Linux in 1992.^[69][70]

Because older versions of DOS could mistake LFN names in the root directory for the volume label, VFAT was designed to create a blank volume label in the root directory before adding any LFN name entries (if a volume label did not already exist).^{[nb 14]}

Each phony entry can contain up to 13 UCS-2 characters (26 bytes) by using fields in the record which contain file size or time stamps (but not the starting cluster field, for compatibility with disk utilities, the starting cluster field is set to a value of 0. See 8.3 filename for additional explanations). Up to 20 of these 13-character entries may be chained, supporting a maximum length of 255 UCS-2 characters.^[55]

If the position of the LFN's last character is not at a directory entry boundary (13, 26, 39, ...), then a 0x0000 terminator is added in the next character position. Then, if that terminator is also not at the boundary, remaining character positions are filled with 0xFFFF. No directory entry containing a lone terminator will exist.

LFN entries use the following format:

If there are multiple LFN entries required to represent a file name, the entry representing the end of the filename comes first. The sequence number of this entry has bit 6 (0x40) set to represent that it is the last logical LFN entry, and it has the highest sequence number. The sequence number decreases in the following entries. The entry representing the start of the filename has sequence number 1. A value of 0xE5 is used to indicate that the entry is deleted.

On FAT12 and FAT16 volumes, testing for the values at 0x1A to be zero and at 0x1C to be non-zero can be used to distinguish between VFAT LFNs and pending delete files under DELWATCH.

For example, a filename like "File with very long filename.ext" would be formatted like this:

A checksum also allows verification of whether a long file name matches the 8.3 name; such a mismatch could occur if a file was deleted and re-created using DOS in the same directory position. The checksum is calculated using the algorithm below. (pFCBName is a pointer to the name as it appears in a regular directory entry, i.e. the first eight characters are the filename, and the last three are the extension. The dot is implicit. Any unused space in the filename is padded with space characters (ASCII 0x20). For example, "Readme.txt" would be "README␠␠TXT".)

unsignedcharlfn_checksum(constunsignedchar*pFCBName){inti;unsignedcharsum=0;for(i=11;i;i--)sum=((sum&1)<<7)+(sum>>1)+*pFCBName++;returnsum;}

If a filename contains only lowercase letters, or is a combination of a lowercase basename with an uppercase extension, or vice versa; and has no special characters, and fits within the 8.3 limits, a VFAT entry is not created on Windows NT and later versions of Windows such as XP. Instead, two bits in byte 0x0C of the directory entry are used to indicate that the filename should be considered as entirely or partially lowercase. Specifically, bit 4 means lowercase extension and bit 3 lowercase basename, which allows for combinations such as "example.TXT" or "HELLO.txt" but not "Mixed.txt". Few other operating systems support it. This creates a backwards-compatibility problem with older Windows versions (Windows 95 / 98 / 98 SE / ME) that see all-uppercase filenames if this extension has been used, and therefore can change the name of a file when it is transported between operating systems, such as on a USB flash drive. Current 2.6.x versions of Linux will recognize this extension when reading (source: kernel 2.6.18 /fs/fat/dir.c and fs/vfat/namei.c); the mount option shortname determines whether this feature is used when writing.^[71]

• Comparison of file systems
• Drive letter assignment
• exFAT
• Extended Boot Record (EBR)
• FAT filesystem and Linux
• List of file systems
• Master Boot Record (MBR)
• Partition type
• Timeline of DOS operating systems
• Transaction-Safe FAT File System
• Turbo FAT
• Volume Boot Record (VBR)

• ECMA-107 Volume and File Structure of Disk Cartridges for Information Interchange, identical to ISO/IEC 9293.
• Microsoft Extensible Firmware Initiative FAT32 File System Specification, FAT: General Overview of On-Disk Format
• Understanding FAT32 file systems (explained for embedded firmware developers)
• Understanding FAT including lots of info about LFNs
• Detailed Explanation of FAT Boot Sector: Microsoft Knowledge Base Article 140418, copy made by Internet Archive Wayback Machine
• Description of the FAT32 File System: Microsoft Knowledge Base Article 154997, copy made by Internet Archive Wayback Machine
• FAT12/FAT16/FAT32 file system implementation for *nix: Includes libfat libraries and fusefat, a FUSE file system driver
• MS-DOS: Directory and Subdirectory Limitations: Microsoft Knowledge Base Article 39927, copy made by Internet Archive Wayback Machine
• Overview of FAT, HPFS, and NTFS File Systems: Microsoft Knowledge Base Article 100108
• Volume and file size limits of FAT file systems: Microsoft Technet, copy made by Internet Archive Wayback Machine
• Microsoft TechNet: A Brief and Incomplete History of FAT32 by Raymond Chen
• FAT32 FormatterArchived 2009-07-21 at the Wayback Machine: allows formatting volumes larger than 32 GB with FAT32 under Windows 2000, Windows XP and Windows Vista
• Fdisk does not recognize full size of hard disks larger than 64 GB: Microsoft Knowledge Base Article 263044, copy made by Internet Archive Wayback Machine. Explains inability to work with extremely large volumes under Windows 95/98.
• Microsoft Windows XP: FAT32 File System. Copy made by Internet Archive Wayback Machine of an article with summary of limits in FAT32 which is no longer available on Microsoft website.
• Visual Layout of a FAT16 drive