אוקי, המעט שאני יודע
ותקנו אותי אם אתם מוצאים טעויות, כי לא ממש טרחתי ללמוד את החומר התיאורטי יותר מדי, בעניין הזה (יש לענות לשאלות בפורום, ולשחק במחשב, ולעבוד - הקיצר, אין זמן). נתחיל ב FAT (עם הרחבה ל FAT32). FAT היא מערכת הקבצים הראשונה שהציעה מיקרוסופט עבור מחשבי IBM (נדמה לי שהם קנו אותה, אבל...). והיא מיצגת File Allocation Table. בבסיסה מבוססת חלוקה לוגית של הכונן הקשיח למספר סופי וקבוע של יחידות לוגיות, כאשר בכל יחידה יכול להתאכסן חלק (או כל) מקובץ יחיד. לא יתכן מצב שבו יחלקו שני קבצים (או חלקים משניהם) את אותה יחידה (כלומר, יתכן, אבל לא תקין). ישנן שתי טבלאות "הצבעה" - בתחילת מערכת הקבצים, ובסופה, ובדיקת תקינות מבוססת גם על השוואה ביניהן. מכיוון שמספר היחידות סופי, ומבוסס על 16 סיביות, יש לנו הגיון פשוט. נניח, לשם הציוריות, שיש לנו דף משבצות פוליו אחד, אותו אנחנו צריכים לחלק ל N סופי מקטעים. גודל כל מקטע יגזר מגודל הדף עצמו. כל מקטע ייוצג על ידי משבצת אחת בראשית הדף (ומשבצת תואמת בסופו) שמכילה שם (לשם העניין, שם יכול להכנס בדיוק בתוך משבצת) - כאינדקס מיקום בדיסק. אם יש לנו שם "יוסי" שתופס מקטע וקצת, הרי שמבחינת האינדקס שלנו, הוא ממלא שתי משבצות בטבלה (האינדקס שלנו, שווה ערך מבחינת צורה לטבלה. אה, הטבלאות בראשית ובסוף זהות מבחינתינו, לכן אני לא אציין שהן שם פעמיים כל פעם), כי אי אפשר למלא "משבצת וקצת". כלומר, בזבזנו מקום מועט (לא קריטי מאוד). הגודל שמיוצג על ידי כל משבצת בטבלה תלוי בגודל הדף. אם נשתמש באותו מספר משבצות לטבלה, אזי על דף "חצי פוליו", כל משבצת תייצג מקטע קצר יותר, וכך נגיע לניצול טוב יותר של מקום (פחות ביזבוז). בואו נגיד, במקרה, שהראש של הדיסק הקשיח, כל כך וכך מידע שנקרא, מחוייב לגשת לטבלה (רק זאת שבהתחלה, אגב), וזה חריף יותר עבור שינוי קבצים (כלומר, אם הקובץ לא נמצא מייד אח"כ, הוא צריך לעצור ולחפש אותו). כל כך וכך קבצים יהיה על ראש הדיסק לחפש בטבלה את מיקום הקובץ הבא. זה עוד לא נורא, מה שממש גרוע זה שכמתודת כתיבה, מערכת הקבצים תכתוב על המקטע הקרוב ביותר להתחלה, בין אם הוא מספיק או לא. אם לא, אז ממשיכים לבא הקרוב ביותר, וכן הלאה. אם מחקת עכשיו שלושים אובייקטים קצרים (שתפסו מספר מועט של מקטעים, כל אחד) מהדף, והיו מפוזרים, ועכשיו אתה מכניס אובייקט גדול, הוא יפוזר בכל הדיסק. הראש יתחיל לקרוא את הקובץ, ירוץ לטבלה לבדוק היכן ההמשך, יקרא את ההמשך, ירוץ לטבלה לחפש את ההמשך הבא, ירוץ להמשך הבא וכן הלאה. בקריאה הדיסק שלך במיטבו, בחיפוש, לא. התוצאה תהיה נפילה משמעותית בביצועים. איחוי פותר את הבעיה הזאת, כך שבמהלך פעולה ארוכה מאוד של הזזה, הקבצים "מאוחים" לכדי אחידות, כדי שקובץ יתפוס מקטעים סמוכים, ולא מפוזרים. נורטון, בתוכנת ה SpeedDisk שלהם הגדילו לעשות, ואף שינו מיקומי קבצים לפי כמות הגישות אליהם, הסמיכות הנדרשת ביניהם (מערכת ההפעלה לתחילת הדיסק, לדוגמא), גודלם, והאם הם ספריות. מגבלה נוספת של fat היא בכמות הקבצים שניתן להכניס בספריה בודדת (אלפים בודדים), ובכמות הקבצים בספריית האב (כולל ספריות *לעולם* לא מעל 512 - כל קרבה למספר הזה תגרור נפילת ביצועים שלא ידעתם כמותה. זאת אחת ההתקפות הנפוצות של netbus, כמעט בלי נפח, רק ספריות ריקות). חיסרון נוסף הוא שכמות וגודל הטבלה מוגבלים, ותומכים רק עד חלוקות של 2GB, בגודל אשכולות של 32k (כל ספריה עולה לך 32k רק ביצירה) - ביזבוז עצום. אם יתבצע ההיפך, והמקטעים יוקטנו למינימום (בהנחה ואפשר), ראש הדיסק יגש כל הזמן, גם באמצע קבצים קטנים, לטבלה לבדוק מה קורה. אין מנצחים... FAT32 עולה על אחיו בכך שהמציין מתבסס על אורך של 32 סיביות, ובכך מאפשר תמיכה במחיצות גדולות פי אלפים, "משבצות" שמצביעות על מקטעים קטנים יותר (חסכון בנפח), תמיכה (עד כמה שאני יודע) במחיצות עד 2TB, ותוספת נחמדה - בטבלה עצמה מצויין אם מקטע מלא לחלוטין או לא (מאוד עוזר לאיחוי). אני אעשה הפסקה קטנה, ואחזור עם NTFS. Ez
