למה הנפחים של הכוננים הקשיחים לא גדל?

[Milford Cubicle]

אני את הגיבוי שלי עשיתי בצורה הבאה: כל מה שחשוב לי והכל ( המערכת הפעלה מן הסתם גם כן ), עובד על מערך RAID 0 של זוג SSD של EVO 250.

אני מקווה שהתבלבלת ורצית לכתוב RAID 1.

RAID 0 הוא לא מערך שנועד לגיבוי אלא בדיוק להיפך. הוא מכפיל פי-2 את הסיכון לאיבוד המידע.

[Art Tatum]

זה למה יש לי כלל אף פעם לא לקנות מעבר לקיבולת הנחוצה מעבר למקרים יוצא דופן (הצפה למשל קופצת לראש גרררררר) והזדמנויות חריגות.

עד שיעבור הזמן ותזדקק לשטח אכסון נוסף כבר תוכל לרכוש נפחים גדולים יותר במחיר נמוך יותר (תאורטית).

לא מדויק.

הטעות שלו שהוא קנה שני כוננים מראש מבלי לדעת בדיוק לאן הוא הולך איתם.

כשקונים יחידה אחת כמעט תמיד כדאי לקנות את הנפח המשתלם ביותר במחיר פר גיגה.

גם כי בטווח הארוך זה בדרך כלל יותר משתלם כלכלית פר גיגה מאשר הוספת כונן נוסף.

וגם כי בדרך כלל נפח זמין קובע את הצורך, יותר ממה שצורך קובע את הנפח.

כך שהכלל המומלץ(מבחינתי) הוא לקנות תמיד את הכונן המשתלם ביותר פר גיגה, ולהוסיף עוד כונן הכי משתלם פר גיגה כשהכונן הראשון לא מספיק.

נכון לתאריך זה, כונן 3TB.

רק במקרים בהם המשתמש יודע ב100% מה הוא צריך או לא צריך, מתוך ידיעה, ולא מתוך חוסר ידיעה, אז אולי יש טעם בלקנות כונן בנפח קטן שבאופן טבעי פחות משתלם פר גיגה.

וגם אז אם שוקלים את מגוון האפשרויות, אולי יהיה עדיף לעשות שימוש בכונן משומש ממחשב אחר שלכם/משפחה/חברים, ובאותו הכסף לעשות שימוש כחלק מקניית כונן חדש יותר משתלם פר גיגה למחשב בו יהיה בכך תועלת.

אך זה דורש מחשבה רחבה יותר, וידע בסיסי בפירוק הרכבה ואולי גם תוכנה(לMIGRATION של מערכת הפעלה), קצת מאמץ, וזמן כמובן.

[ABL]

גם אני חושב ככה, מלבד למי שרוצה ליצור 2 כוננים ( לא במערך RAID ) בכדי באחד למלא אותו בשטויות ובשני לבצע גיבוי.

אני את הגיבוי שלי עשיתי בצורה הבאה: כל מה שחשוב לי והכל ( המערכת הפעלה מן הסתם גם כן ), עובד על מערך RAID 0 של זוג SSD של EVO 250.

מעבר לכך יש לי כונן 2TB + 320GB שבכל אחד יש עותק של התיקיית גיבוי שלי עם הכל. ב 2TB המהיר והחדש אני עובד עם מה שצריך וה 320GB מגבה אותם.

בזבוז מוחלט של SSD...

[Art Tatum]

בזבוז מוחלט של SSD...

לא מדויק.

RAID 0 זה יופי של תוספת לביצועים.

שימושי והגיוני רק לחולי ביצועים כמובן.

אם ההבדל בין 100MB ל200MB מורגש(והוא מורגש).

גם ההבדל בין 200MB ל400MB מורגש.

וגם ההבדל בין 500MB ל1000MB מורגש.

אומנם ההבדל בין חצי שניה לשניה הוא קטן בראיה הכללית.

וההבדל בין רבע שניה לחצי שניה הוא קטן עוד יותר בראיה הכללית.

וההבדל בין שמינית שניה לרבע שניה הוא כמעט ואינו קיים בראיה הכללית.

אבל אם מטרת חולה הביצועים היא לצמצם גם את הפעולות של ה5 שניות וה10 שניות והחצי דקה, והדקה, ושתי דקות, אז וודאי שRAID 0 של SSD יעשה לו שמח בדגדגן.

[Art Tatum]

נסה להפעיל על המערך PRIMOCACHE(תוכנת BETA חינמית וותיקה ויציבה עם יותר אופציות וביצועים מהRAPID של סמסונג).

מכיוון שיש לך גיבוי, אתה יכול לקחת צ'אנס עם WRITE DEFER ולקוות לטוב(כותב לזיכרון במקום לכונן, ואומר למערכת הפעלה שהנתונים נכתבו כדי שזו לא תצטרך להמתין ברמת התוכנה, ומפנה את הנתונים לכונן בזמנו הפנוי על פי יכולתו).

אצלי יש WRITE DEFER של 10 שניות כבר שנים ללא שום בעיה.

אם אתה ממש הרפתקן, או יש לך UPS פעיל על המחשב, ובעיקר שימושי אם יש לך הרבה זיכרון CACHE להגדיר לו, נסה אולי גם 20-30 שניות כדי לקבל מהירות כתיבה רציפה מדהימה לפעולות ארוכות יותר.

[nat64x]

לא מדויק.

הכוונה הייתה שלא רוכשים כוננים נוספים לפני שיש להם תכלית וכבר ניצלת את השטח הקיים.

אפשר לדחות רכישת כונן נוסף בצורה הזאת בהרבה זמן.

[Art Tatum]

PRIMOCACHE יודע גם לעשות LEVEL 2 CACHING.

אז אם אתה מעוניין להאיץ גם את ההרדיסק(עם ביצועים טובים יותר משמעותית מכוננים היברידים) אתה יכול להגדיר להרדיסק שני רמות CACHE, אחד ע"י הזיכרון והשני על גבי הSSD.

היתרון בSSD CACHING שנקרא בתוכנה LEVEL 2 על הMEMORY CACHING שנקרא LEVEL 1, הוא שLEVEL 2 יכול לקיים CACHE גדול יותר של עשרות(או מאות) גיגה, והמידע נשמר בין איתחולי מערכת וזמין להאצה.

זה בעיקר שימושי לאנשים שמתקינים מאות גיגה של משחקים בו זמנית(פיראטים או משתמשי Steam לדוגמה), ואין להם מקום בSSD להכל.

או לעבודה עם תוכנות מקצועיות בנפחים גדולים במיוחד.

בכל מקרה אם יש לך הרבה זיכרון (16GB ומעלה) הייתי ממליץ לתת לכל אחד מההרדיסקים איזה חצי/גיגה LEVEL 1 עם WRITE DEFER רק בשביל לשמן קצת את הפעולות איתו.

רק קח בחשבון שלWRITE DEFER יש פוטנציאל הרסני על הקבצים הנכתבים(ובמקרים נדירים מאוד אולי גם על מערכת הקבצים כולה) במקרים של קריסה/קצר חשמלי.

אז במיוחד על הרדיסקים להם אין גיבוי, עדיף אולי להימנע מWRITE DEFER ארוך או לגמרי.

בכל זאת אם אתה סקרן/הרפקן/מהמר/בעל-אמונה אולי כדאי לנסות.

אני הפעלתי WRITE DEFER של 10 שניות על הרדיסק מערכת הפעלה במשך שנה בה היו כמה קצרים וקריסות בזמן שהוא פעל.

לכל היותר נהרסו קבצים באותו האופן שהיו נהרסים בעקבות הקצר גם ללא הWRITE DEFER.

בכל זאת אני חייב להזהיר כדי לעשות לעצמי כסת"ח.

[nat64x]

מכיוון שיש לך גיבוי, אתה יכול לקחת צ'אנס עם WRITE DEFER ולקוות לטוב(כותב לזיכרון במקום לכונן, ואומר למערכת הפעלה שהנתונים נכתבו כדי שזו לא תצטרך להמתין ברמת התוכנה, ומפנה את הנתונים לכונן בזמנו הפנוי על פי יכולתו).

אצלי יש WRITE DEFER של 10 שניות כבר שנים ללא שום בעיה.

למערכת ההפעלה יש מנגנון מובנה שעושה את אותה פעולה בדיוק.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa364218(v=vs.85).aspx

אז מה בדיוק היתרון פה לא ברור לי?

ממה שהם כותבים בדף שלהם הם מציינים רק את זה:

Why PrimoCache?

Why do we need another cache scheme since Windows OS has already implemented a file-system level cache?

• Some applications bypass the file-system level cache.
  
• Windows caches all data, while PrimoCache can cache on behalf of a specified volume in which users are interested. Given same size of system memory, the latter has a higher hit-rate.
  

לא נשמע משכנע במיוחד.

נראה שזה רק מוסיף לך קצת אופציות לקסטם מס' הגדרות בנושא (באמת הכרחי?).

נראה לי עדיף כבר להשתמש באיזה תוכנת RAM DISK כשצריך וזהו.

[Art Tatum]

ההבדל בין הWRITE DEFER לWRITE BACK הוא קודם כל בכמות שאתה יכול להגדיר לCACHE.

הזמן המקסימלי בו הCACHE יכול להחזיקו לפני שהוא חייב לכתוב אותו לכונן.

הוינדוס משתמש בכמות מאוד קטנה לזמן מאוד קטן, מה שהופך את הWRITE CACHE שלו למאוד מצומצם ביכולתו להאיץ פעולות כתיבה.

בנוסף יש לPRIMOCACHE אסטרטגיה משולבת לכתיבה וקריאה מול הCACHE.

לדוגמה(היפוטתי) יש לי CACHE ענק של 20GB קריאה/כתיבה עם WRITE DEFER.

עכשיו הורדתי קובץ ARCHIVE של תוכנה בנפח 4GB.

למרות שהוא נכתב לכונן, הוא עדיין נמצא בזיכרון.

אני פורס את הקבצים ממנו, והם עוברים מהזיכרון לזיכרון, כשהכתיבה לכונן נעשת באופן משני לחלוטין לכל התהליך, וחלקה אחרי שהוא הסתיים מבחינת מערכת ההפעלה.

בזמן שהCACHE כותב מהזיכרון לכונן(WRITE DEFER) אני כבר יכול להתחיל את ההתקנה.

עכשיו הPRIMOCACHE כותב לכונן גם את הקבצים שהיו בARCHIVE וגם את התוכנה שהתקנתי איתם.

מהירות כתיבת הכונן אינה רלוונטית לביצועים כי בנפח כל כך גדול של זיכרון CACHE עם WRITE DEFER כל הפעולות כתיבה יתבצעו בזיכרון מבלי לחכות לכונן.

אם אני קורא מהכונן בזמן שהוא כותב אליו, ויש לי DEFER WRITE עם זמן ארוך, הPRIMOCACHE יעכב את הכתיבה ויתמקד בפעולת הקריאה לביצועים מירביים.

גם כשמדובר על LEVEL 1 CACHE בגודל 1GB עם WRITE DEFER של 10 שניות, אתה תראה ותרגיש הבדלי ביצועים בפעולות שונות ובאופן כללי.

אני אתן לך דוגמה.

שמירה או טעינה במשחק בו הגורם המעכב לסיום הפעולה הוא בעיקר או כמעט רק! הכונן עצמו.

במקום 6 שניות זה יקח 3 שניות.

במקום 3 שניות זה יקח שניה אחת.

אני זוכר עוד לפני הSSD(שגם עליו בדקתי ביצועים כמובן), כשהפעלתי PRIMOCACHE שאז נקרא FANCYCACHE על ההרדיסק, שמירה שלקחה קודם 20 שניות הסתיימה ב4 שניות.

אז אתה יכול להבין מזה שהWRITE BACK של הוינדוס לא מתקרב לעוצמת הביצועים והתגובתיות של PRIMOCACHE WRITE DEFER.

גם בקריאה יש יתרונות.

הCACHE של הוינדוס בדרך כלל משמיט לגמרי קבצים גדולים ומעדיף קבצים קטנים.

לPRIMOCACHE לא איכפת מגודל הקובץ או אם זה בכלל קובץ.

כל פעולת קריאה של בלוק שחוזרת על עצמה תהיה בCACHE.

אם אתה משחק במשחק בו יש קובץ אחד גדול בו כל המפות, או קבצים של מפות בהם אתה נמצא רוב הזמן באיזור מסויים, הPRIMOCACHE יאיץ לך את מה שאתה באמת צריך.

בעוד שהוינדוס יתעלם מכך לחלוטין כי הוא לא מסוגל להכיל את גודל הקובץ או מתעדף קבצים קטנים.

זהו תוצר של אופטימיזציה לחולשות ההרדיסק שמובנית לתוך נוסחאות הCACHE של הוינדוס.

אני לא יודע איך בדיוק הRAPID של סמסונג עובד, אבל התוצאות במבחנים הסינטתים מצביעים על יתרון לא קטן לPRIMOCACHE.

[Milford Cubicle]

כשהכל עובד בצורה תקינה הכל טוב ויפה. מה קורה בזמן אסון? מה קורה אם פתאום המחשב נתקע/נכבה? הקבצים אבודים.. מה קורה במצב שאתה עובד על קובץ קיים? רק השינויים נזרקים לפח (לא היסטרי אם זה רק 10 שניות אחורה) או שכל הקובץ הולך לאיבוד?

[Art Tatum]

כשהכל עובד בצורה תקינה הכל טוב ויפה. מה קורה בזמן אסון? מה קורה אם פתאום המחשב נתקע/נכבה? הקבצים אבודים.. מה קורה במצב שאתה עובד על קובץ קיים? רק השינויים נזרקים לפח (לא היסטרי אם זה רק 10 שניות אחורה) או שכל הקובץ הולך לאיבוד?

תיאורטית הכל יכול לקרות, תלוי ברגע המסויים בו האסון קורה(ובגודל הCACHE/הגדרת הזמן לפני כתיבה).

באותה המידה זה יכל לקרות גם ללא הWRITE DEFER, במרחק כמה שניות.

ההבדל הוא שהמערכת הפעלה קיבלה אישור שהקובץ נכתב למרות שחלקו עדיין רק בזיכרון, ואולי עשתה שינויים אחרים המתסתמכים על כך.

לכן יש פוטנציאל לתוצאות שאינן קורות ללא WRITE DEFER.

בתכלס?

עם WRITE DEFER של 10 שניות מעולם לא נתקלתי בבעיה מיוחדת אחרי קריסת מערכת/קצר חשמלי.

וכשיש לך גיבוי למערכת הפעלה, וודאי שאין סיבה לא להנות מתגובתיות משופרת.

[ran_cohen]

אני הלא-מחקן היחיד? במחשב שלי יש לי כונן של חצי טרה עם 8 גיגה פנוי, 2 טרה עם 60 גיגה פנוי, וכונן נשלף של טרה עם חצי גיגה פנוי (וזה אחרי שהתקלקל לי כונן של טרה עם 200 גיגה פנוי...).זה כנראה מה שקורה אם לעולם לא מוחקים קבצים, ודואגים להעביר גיבויים ממחשב אחד לשני (עדיין יש לי קבצים מה486)...

[Milford Cubicle]

אממ...

כונן מערכת SSD 250GB

כונן נתונים 2TB

כונן עבודה 3TB

כונן מדיה (חיצוני) 3TB

כונן גיבוי עבודה (חיצוני) 3TB

.....

רובם מלאים באיזור ה-80%

[arik100]

אני היחיד פה שמצליח להסתדר עם 120GB SSD וזהו?

[OR2OOO]

גם אני "מצליח", אבל מצליח זה לא דבר נוח.

אני רוצה לא לחשוב נל זה בכלל ו-10GB זה לא בדיוק כיף.