אוריק לוסון
טכנולוגיית Fusion Drive החדשה של אפל היא קצת תעלומה. נדחה על ידי חלק כעוד מנגנון מטמון פשוט, הוא משך תשומת לב רבה בשבועות מאז הוכרז. (ורק בסוף השבוע שעבר החלו למשלוח מחשבי Mac מצוידים ב- Fusion Drives.) ל-Ars היה את שלו בידיים על Mac Mini המצויד ב-Fusion Drive כבר כמה ימים, והצבנו את עצמנו לאתגר לפתור את מִסתוֹרִין. בילינו כמה ימים במרפקים עמוקים בטכנולוגיה, בניסיון לקבוע כיצד פועל Fusion Drive (להלן FD) ואיזו השפעה יש לו על ביצועי המערכת הכוללים. רצינו גם לראות מה קורה עם התקנת Windows דרך Boot Camp, ומה קורה כאשר Fusion Drive נכשל. למדנו הרבה בזמן קצר באמצעות התבוננות ודדוקציה, ולמרות שחלק מהשאלות עדיין חסרות מענה, קיבלנו הרבה מידע יוצא דופן ובלעדי.
כדי לסקור בקצרה, FD הוא תכונה הכריז מאת פיל שילר באירוע אפל ב-23 באוקטובר, שהוכרז גם ב-Mac Minis וב-iMac החדשים באירוע. FD משתמש ב-Core Storage כדי ליצור אמצעי אחסון בודד מדיסק מוצק ומכונן דיסק קשיח מסורתי גדול בהרבה, ולאחר מכן מסדר נתונים הלוך ושוב בין השניים. המטרה היא לספק את המהירות של SSD, תוך ניצול הגודל הגדול של הדיסק הקשיח כדי להחזיק את עיקר הנתונים שלך. עם זאת, באופן טיפוסי של אפל, המצגת הייתה גבוהה בהפרבולות אך נמוכה בבשר טכני ממשי. עשינו עוד שתי הצצות ב-FD, אחת
צולל לתוך ההאקרי המרשימה שנעשתה על ידי פטריק שטיין (המכונה "Jollyjinx"), שגילה שנראה ש-FD עובד על כל מק עם גרסה 10.8.2, לא רק על מיני ו-iMacs חדשים. האחר מְפוֹרָט תוצאות מעשיות ראשוניות עם ה-Mac Mini המצויד ב-FD שלנו.Ars השיגה גם את מסמך ההדרכה של טכנאי השירות של אפל עבור Fusion Drive, הודות למקור אנונימי מועיל. המסמך שופך יותר אור על הטכנולוגיה, ומאשר מספר דברים העלינו השערות על אודות. במיוחד, הוא מציין בסוף 2012 מחשבי iMac 21" ו-27.5 אינץ' מגיעים עם "מודולי אחסון" הבזק, בדומה לאלו שכבר נראו ב-MacBook Airs וב-Retina MacBook Pros. מכשירי Mac Mini בסוף 2012 משתמשים ב-SSD בגודל 2.5 אינץ' במקום במודול אחסון.
ההדרכה עדיין מתייחסת ל-FD להעביר "אפליקציות ומסמכים" בין SSD ל-HDD, אם כי בדיקות הראו שזה לא ממש נכון. FD פועל מתחת לקבצים, למעשה מעביר בלוקים של Core Storage (שנראה שמכונה באופן פנימי "חתיכות", כפי שנראה). עם זאת, הצגת הטכנולוגיה של אפל כ"אפליקציות ומסמכים" נעה היא הגיונית לחלוטין: קל להסביר אפליקציות ומסמכים בהפעלה מהירה מצגת, בעוד דיון ממשי של קבצים מול אשכולות מערכת קבצים מול בלוקים של אחסון ליבה לעומת בלוקים של דיסקים יהיה קשה לדחוס לתוך שקופית בודדת.
חיטטנו ודחפנו ב-Fusion Drive Mac Mini כל סוף השבוע, וחפרנו המון מידע עסיסי נוסף על תפקוד ה-FD בעולם האמיתי. התעמקנו גם במה שקורה כשדברים משתבשים.
חצי כוס מלאה
המגיבים במאמרים האחרים - במיוחד אלה שרק רפרפו בטקסטים - תהו ארוכות מדוע אנו מוציאים כל כך הרבה דיו (וירטואלי) בכיסוי Fusion Drive. האם זה לא רק פתרון מטמון פשוט? האם זה לא זהה לאינטל SRT? האם לינוקס לא עושה את זה מאז 1937?
לא, לא, ולא. של אינטל טכנולוגיית תגובה חכמה היא תכונה זמינה בערכות השבבים החדשות יותר שלה Ivy Bridge, והיא מאפשרת שימוש ב-SSD (בגודל של עד 64GB) כמטמון כתיבה או כתיבה עבור הכונן הקשיח של המחשב. הבדל משמעותי אחד בין FD לטכנולוגיית מטמון כמו Intel SRT הוא ש-Fusion Drive משנה את המיקום הקנוני של הנתונים שהוא משלב, להעביר אותו (מעתיק אותו, באמת, כי אנחנו לא רואים קריאת "מחק" למערכת קבצים במהלך הגירות Fusion, כפי שנראה עוד מעט) מ-SSD ל HDD. חשוב מכך, עם FD, נתונים רבים ככל האפשר עוברים תחילה ל-SSD, כאשר נתונים נשפכים מה-SSD אל ה-HDD. תמונה SSD של Fusion Drive כמו כוס שתייה קטנה, וה- HDD הוא דלי הרבה יותר גדול, מתחת ל-SSD. כאשר אתה מכניס נתונים על פיוז'ן דרייב, זה כאילו אתה שופך מים לכוס; בסופו של דבר, כשהכוס מתמלאת, המים משתפלים על הצד ומתחילים להיתפס על ידי הדלי. עם Fusion Drive, אתה תמיד מוזג לכוס וזה נשפך לדלי לפי הצורך.
מצד שני, פתרונות אחסון במטמון כמו SRT קובעים באופן אלגוריתמי אילו דברים יש לשקף מ-HDD ל-SSD. למרות שניתן להשתמש ב-SSD כמטמון כתיבה, מיקום ברירת המחדל של הנתונים הוא ב-HDD, לא ב-SSD. ב-Caching, ה-HDD הוא התקן האחסון איתו אתה מתקשר, וה-SSD משמש להגברת המהירות של ה-HDD. ב-Fusion Drive, ה-SSD הוא המכשיר איתו אתה מקיים אינטראקציה והדיסק הקשיח משמש להגדלת הקיבולת של ה-SSD.
אני בהחלט לא מסתכל על פיוז'ן דרייב, וזה לא דבר חדש מהפכני שיעשה לגרום למחשב שלך לירות קשתות מתוך חריצי ה-USB שלו תוך ריפוי סרטן והפיכת ילדים חולים לבריאות שוב. עם זאת, כפי שנראה, Fusion Drive היא טכנולוגיית שכבות שקופה שפשוט עובד. זו הפונקציונליות התמיד-על חלקה שהופכת את זה לחדשות - אתה קונה מחשב עם Fusion Drive מופעל ואין צורך להתקין או להגדיר חומרה או תוכנה נוספת כדי ליהנות ממנה יתרונות.
מר פיוז'ן
כדי לאמת את מה שאפל אומרת בהכשרה שלה, ומכיוון שאנחנו פשוט לא יכולים לעזוב מספיק טוב, לקחנו מברג וספדג'ר למיני המושלם שלנו ופירקנו אותו לחלקים המרכיבים אותו. רצינו לראות בעצמנו בדיוק איזה סוג של SSD יש שם.
לי האצ'ינסון
לי האצ'ינסון
מדובר ב-Samsung 830 מבוסס MZ-5PC1280, לפי הדיווחים אותו סוג של משלוח SATA III SSD עם Macbook Pros נוכחיים שאינם רשתית, אם כי ככל הנראה עם קושחה מעודכנת. הוא מגיע רכוב במפרץ HDD התחתון של המיני, מחובר ללוח האם בצורת L עם מתאם.
לי האצ'ינסון
למרות שאכן יש שני דיסקים פיזיים, FD מאחד אותם לנפח אחד. מנקודת מבט של משתמש, מדובר בדיסק בודד, ואתה מקיים אינטראקציה עם עוצמת הקול של FD בדיוק באותה צורה כמו בדיסק רגיל. אין צורך בתצורה או התעסקות.
הביצועים הם בדיוק היכן שהייתם מצפים שיהיו עבור SSD ברמה בינונית, עם מספרי דיווח של XBench טובים, אך לא מצטיינים. למרבה האמירה, אין שום דרך לשפר את הדיסק הקשיח - ה-benchmark מחיל את עצמו על תת-מערכת הדיסק, ו-Core Storage מבטיח שהוא מתממשק עם ה-SSD.
כדי לראות את ה-SSD וה-HDD בנפרד, אתה צריך לרדת קצת יותר למטה ולמשוך את שורת הפקודה diskutil הפקודה, שמראה שה-SSD וה-HDD של המיני הם בהחלט שני מכשירים פיזיים נפרדים:
LeeHs-Mac-mini:~ leeh$ diskutil cs list CoreStorage logical volume groups (1 found) | +-- Logical Volume Group 31CBA650-4ABC-4DA6-AA73-6D96B36693E2 Name: Macintosh HD Size: 1120333979648 B (1.1 TB) Free Space: 0 B (0 B) | +-< Physical Volume F4A50F9C-841D-4C6D-AFC4-6A10560E0717 | | Index: 0 | Disk: disk0s2 | Status: Online | Size: 120988852224 B (121.0 GB) | +-< Physical Volume C86789FD-1978-453A-BCA7-81DC05AA66C7 | | Index: 1 | Disk: disk1s2 | Status: Online | Size: 999345127424 B (999.3 GB) | +-> Logical Volume Family AA92FDF8-F962-4DE3-AC2F-1B6ABF22AA22 Encryption Status: Unlocked Encryption Type: None Conversion Status: NoConversion Conversion Direction: -none- Has Encrypted Extents: No Fully Secure: No Passphrase Required: No | +-> Logical Volume B97C9558-14FC-4BFC-B413-AFB292BD29F0 Disk: disk2 Status: Online Size (Total): 1115853029376 B (1.1 TB) Size (Converted): -none- Revertible: No LV Name: Macintosh HD Volume Name: Macintosh HD Content Hint: Apple_HFS
אם אתה משתמש מזדמן ולא אכפת לך מהחלק הפנימי, אין שום דבר שאתה צריך לעשות כדי לגרום ל-FD "לעבוד". אתה מדליק את המערכת, נכנס למערכת ומשתמש בה. מק המצויד ב-Fusion Drive עוזב את המפעל עם מערכת ההפעלה וכל המותקנים מראש יישומים בצד ה-SSD, כך שהמערכת קלה ומגיבה בדיוק כאילו הייתה SSD בלבד מק. זמני האתחול מחוץ לקופסה במיני היו מהירים להפליא, כאשר המערכת עוברת מלחיצת כפתור להנחיית כניסה תוך כשבע שניות על ידי שעון העצר שלי. התיעוד של אפל מצביע על כך ש-FD תמיד ישמור על מערכת ההפעלה וקבצים קריטיים אחרים מוצמדים ל-SSD, כך שהקלילות הזו צריכה להימשך לאורך כל חיי ה-Mac.
לחפור עמוק יותר
זה הכל בסדר וטוב עבור מערכת חדשה לגמרי, אבל רצינו לדעת איך FD מטפל בדברים במהלך שימוש רגיל. אחד הדברים הראשונים שאנשים רבים הולכים לעשות למק חדש הוא להעביר אליו את הנתונים הקיימים שלהם, ולכן ניסינו לגלות כיצד FD מתנהג כשמשהו כזה קורה. דיווחים ראשוניים מ-Anandtech ציין ש-FD שומר "אזור נחיתה" של 4GB על ה-SSD, ושכל הכתיבה הופנה לאזור הנחיתה הזה. זה לא נראה נכון. או, ליתר דיוק, נראה שזה נכון חלקית, אבל לא לגמרי.
מחוץ לקופסה, המערכת הראתה רק כ-10GB בשימוש. העתקתי קובץ של 3GB מה-NAS שלי למטה אל ה-Mini תוך ניטור התפוקה של הכוננים הפיזיים עם iostat, וכל ה-IO התרחש ב-SSD. לאחר השלמת ההעתקה, נתתי ל-Mini לשבת כשעה כדי לראות אם הוא יעביר חלק מהקובץ או את כולו למטה ל- HDD, אך לא התרחשה תזוזה. העתקתי קובץ שני בנפח 3GB וצפיתי באותה התנהגות - העותק נחת על ה-SSD, ונראה שהוא נשאר שם. עקבתי אחרי זה עם קובץ גדול של 8GB, שגם נחת כולו על ה-SSD ונשאר שם. לאורך כל זה, iostat לא הראה פעילות כלל בדיסק הקשיח.
"אזור הנחיתה" של 4GB לא הופיע בשום מקום בתוצאות, אז החלטתי לחקות התנהגות טיפוסית של "משתמש נכנס" על ידי מילוי ה-SSD בדברים כדי לראות איזה FD הייתי עושה. העתקתי כ-120 ג'יגה-בייט של קבצים, מה שיותר ממלא את ה-SSD ויאלץ את המערכת להראות לי את התנהגות המגירה שלה.
כשההעתקה התחילה, כל הנתונים עברו ל-SSD, בדיוק כמו קודם. כאשר כמות הנתונים ב-SSD הגיעה לכ-110 ג'יגה-בייט (בערך בגודל של מחיצת Core Storage ב-SSD), ה-IO עבר בצורה חלקה מה-SSD (disk0 בתוך ה iostatפלט למטה) ל-HDD (דיסק1), מבלי להפריע להעתקה:
disk0 disk1 KB/t tps MB/s KB/t tps MB/s 915.91 141 125.98 0.00 0 0.00 1016.09 129 127.88 0.00 0 0.00 1014.97 113 111.93 0.00 0 0.00 1011.56 82 80.92 0.00 0 0.00 1016.03 128 126.84 0.00 0 0.00 1016.09 129 127.84 0.00 0 0.00 1013.48 97 95.88 0.00 0 0.00 1024.00 96 95.96 0.00 0 0.00 958.58 48 44.91 1007.30 57 56.04 4.00 1 0.00 1010.16 74 72.92 8.00 24 0.19 1024.00 66 65.92 4.00 2 0.01 1010.53 76 74.95 15.43 7 0.11 974.74 70 66.59 4.00 1 0.00 912.00 82 72.95 4.00 1 0.00 931.33 96 87.21
עבודת ההעתקה המשיכה להסתיים ללא בעיה. כל זה נעשה על גבי Gigabit Ethernet מ-Synology DS412+ NAS; שים לב שה-SSD מסוגל להטמיע קבצים במה שמסתכם במהירות קו (ג'יגה-ביט Ethernet מסתיים בערך 120 MB לשנייה, תוך התחשבות במעט תקורה), בעוד שהדיסק הקשיח האיטי יותר של 5400 סל"ד לא יכול לכתוב כמעט כמו מָהִיר.
הייתי מעוניין לראות מה FD יעשה לאחר סיום העבודה, והמערכת לא אכזבה. הייתה הפסקה של כעשרים שניות, ואז FD החל להעביר נתונים. בהתבסס על התפוקה הנצפית וכמות הנתונים שהועברו, ברור ש-FD העביר דברים מה-SSD ל-HDD:
disk0 disk1 KB/t tps MB/s KB/t tps MB/s 4.00 1 0.00 1010.35 75 73.90 4.00 3 0.01 1024.00 72 71.94 4.00 1 0.00 1009.97 73 71.90 5.33 3 0.02 932.87 78 70.99 8.00 38 0.30 1011.09 79 77.91 4.80 10 0.05 969.86 56 52.98 0.00 0 0.00 999.47 75 73.14 4.00 1 0.00 404.18 88 34.70 30.72 304 9.11 748.71 68 49.66 30.29 295 8.71 484.47 93 43.94 29.43 318 9.13 0.00 0 0.00 29.89 316 9.21 0.00 0 0.00 30.78 289 8.68 0.00 0 0.00 20.92 646 13.20 0.00 0 0.00 29.62 468 13.55 0.00 0 0.00 23.18 428 9.70 75.83 46 3.40 29.27 406 11.62 0.00 0 0.00 29.69 239 6.92 4.00 1 0.00 28.89 369 10.40 0.00 0 0.00 29.09 517 14.68 0.00 0 0.00 disk0 disk1 KB/t tps MB/s KB/t tps MB/s 30.12 455 13.39 0.00 0 0.00 28.90 587 16.57 0.00 0 0.00 30.40 25 0.74 69.92 50 3.41 0.00 0 0.00 0.00 0 0.00 13.33 156 2.03 6.67 3 0.02 0.00 0 0.00 0.00 0 0.00 8.00 9 0.07 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 128.00 202 25.21 128.00 202 25.21 128.00 455 56.90 128.00 454 56.78 125.69 359 44.12 128.00 353 44.18 111.18 427 46.39 128.00 367 45.92 128.00 485 60.64 128.00 484 60.52 119.74 667 78.00 128.00 622 77.76 124.13 681 82.54 128.00 659 82.36 128.00 665 83.13 128.00 665 83.13 123.59 597 72.06 128.00 575 71.89 128.00 679 84.88 128.00 678 84.75 123.42 683 82.31 128.00 658 82.25 disk0 disk1 KB/t tps MB/s KB/t tps MB/s 123.56 676 81.56 128.00 650 81.24 128.00 503 62.91 128.00 503 62.91 122.32 506 60.47 128.00 483 60.41 128.00 643 80.38 128.00 642 80.25 122.73 682 81.74 128.00 652 81.50 123.80 685 82.82 128.00 662 82.75 128.00 565 70.64 128.00 564 70.52 122.57 529 63.34 128.00 506 63.28 128.00 555 69.40 128.00 555 69.40 121.91 708 84.28 128.00 672 84.00 128.00 661 82.63 128.00 661 82.63 122.28 586 69.96 128.00 558 69.74 128.00 458 57.28 128.00 457 57.16 108.32 381 40.34 127.76 319 39.86
זה היה בקורלציה עם fs_usage, שהראה קריאות מ disk0 וכותב ל disk1, יחד עם מה שהן כמובן שיחות Core Storage המתרחשות בין כל אחת מהן:
15:33:27.189432 RdChunkCS D=0x00debd00 B=0x20000 /dev/disk0s2. 0.000328 W kernel_task.1760115:33:27.189468 RdBgMigrCS D=0x0033d8a0 B=0x20000 /dev/CS. 0.000367 W kernel_task.1760115:33:27.190136 WrChunkCS D=0x0aeac500 B=0x20000 /dev/disk1s2. 0.000629 W kernel_task.1760115:33:27.190172 WrBgMigrCS D=0x0033d8a0 B=0x20000 /dev/CS. 0.000670 W kernel_task.1760115:33:27.190531 RdChunkCS D=0x00debe00 B=0x20000 /dev/disk0s2. 0.000328 W kernel_task.1760115:33:27.190568 RdBgMigrCS D=0x0033d8c0 B=0x20000 /dev/CS. 0.000369 W kernel_task.1760115:33:27.191233 WrChunkCS D=0x0aeac600 B=0x20000 /dev/disk1s2. 0.000627 W kernel_task.1760115:33:27.191269 WrBgMigrCS D=0x0033d8c0 B=0x20000 /dev/CS. 0.000667 W kernel_task.1760115:33:27.191638 RdChunkCS D=0x00debf00 B=0x20000 /dev/disk0s2. 0.000336 W kernel_task.1760115:33:27.191673 RdBgMigrCS D=0x0033d8e0 B=0x20000 /dev/CS. 0.000376 W kernel_task.17601
ארבע השיחות המפורטות, "RdChunkCS," WrChunkCS," "RdBgMigrCS" ו-"WrBgMigCS", כולן מוזכרות ב- fs_usageמָקוֹר בתור פעולות Core Storage; השניים האחרונים מצוינים בהערות הקוד כמתייחסים לשיחות "הגירה של בלוק דיסק מורכב". זוהי פעילות "השכבות" בפועל שמהווה את הליבה של Fusion Drive. הבלוקים שאליהם מפנים הם עוקבים (על disk0, התהליך הוא בלוק קריאה 0x00debd00, לאחר מכן 0x00debe00, ואז 0x00debf00), וגודל הנתח האמיתי המועבר הוא 128KB (0x20000 בתים).
תהליך ההגירה של FD נמשך פרק זמן קצר (אם כי ארוך יותר מ- iostat פלט למעלה), ואז הופסק. סיכמתי את כמות הנתונים שהועתקו, וזה יצא ל-4GB בערך.
העתקתי שוב ושוב קבצים גדולים לכונן, והתוצאות נשארו עקביות - פעולות ההעתקה ינחת על ה-SSD עד שיתמלא, ואז יעבור בצורה חלקה ל-HDD וימשיך עד סִיוּם. ה-SSD יעביר מיד נתונים מעצמו עד שיהיה לו 4GB של מקום פנוי. אם הייתי מעתיק קובץ של 2GB, זה היה מוריד 2GB של נתונים ממקום אחר ל-HDD; אם הייתי מעתיק קובץ של 1GB, הוא יורד ב-1GB. אם הייתי מעתיק ל-50GB, הוא יבלע בצורה חלקה את כל ה-50GB, ואז יורד 4GB של נתונים מה-SSD.
המאגר הזה של 4GB הוא בהחלט מה שהמקור של Anandtech התכוון. FD אינו שומר על "אזור נחיתה" קבוע של 4GB אם כמות שטח ה-SSD הפנוי גדולה מ-4GB; אלא, FD שומר על א מינימום 4GB פנוי ב-SSD.
