כותב אפסים ? עסוק ? איפו מצאת את ההסבר הזה ??

בעצמי, עם כמה כלי ניטור סטנדרטיים: Procmon כדי לראות את היצירה של הקובץ בגודלו המלא כבר בתחילת ההורדה, Windows Explorer כדי לראות שאכן קיים בתיקיית ההורדות קובץ בגודלו הסופי כבר בהתחלה, אוזניים כדי להקשיב ל-HDD טוחן כתיבות (עוד לפני ימי ה-SSD היפים), Hex Viewer כדי לראות שהקובץ אכן מלא באפסים ומתמלא לאורך ההורדה.

מוזמן לנסות בעצמך.

מהירות כתיבה אקראית של הארד דיסק היא כמה מגות בודדות.

ההארד דיסק הכי מהיר בשוק כותב רק 2.7 מגה לשניה.

http://www.anandtech.com/show/5729/western-digital-velociraptor-1tb-wd1000dhtz-review/2

הארד דיסקים רגילים זה בסביבות ה-1 מגה.

זו בעייה ידועה ב- utorrent, אחת הפתרונות זה להעלות את הCach (תמצא את זה ב- Advanced תחת Disk cach), לא תמיד זה עוזר.

לאחרונה הורדתי קובץ בגודל 615GB~ וחיברתי במיוחד בשבילו HDD חדש, והייתי מקבל disk overloaded וזה גם היה תוקע לי את התוכנה- הפתרון שלי היה לא להוריד את הכל בבת אחת אלא בחלקים (בדר"כ ההורדה מחולקת לכמה חלקים)

כותב אפסים ? עסוק ? איפו מצאת את ההסבר הזה ??

ההסבר שלו נכון. זה נקרא full allocation ונועד כדי למנוע פרגמנטציה בדיסק. אם אתה מוריד טורנט שיש בו יותר מקובץ אחד, ו full allocation לא מופעל, אז הדיסק יכתוב חלק קטן של קובץ A ולאחריו חלק קטן של קובץ B וכו' (הרי הקבצים יורדים במקביל) וזה ייצור פרגמנטציה רצינית מאוד של אותם קבצים.

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

זה קורה כבר המון זמן ביוטורנט (יותר משנה בוודאות)

גם על ssd

הפתרון היחיד זה להגדיל את הcache כמו שהציעו

אגב, זה לא קורה בקליינט שלהם לos x

לגבי האפסים:

תמהני. מאד.

http://en.wikipedia.org/wiki/Sparse_file

כבר EMULE ידע והשתמש בזה.

גם יוטטורנט יודע וניתן להגדיר ולהשתמש בזה.!

נסו לשנות. (אני לא חושב שזה יעזור ושיש קשר לבעיה המקורית. ).

מהירות כתיבה אקראית של הארד דיסק היא כמה מגות בודדות.

ההארד דיסק הכי מהיר בשוק כותב רק 2.7 מגה לשניה.

http://www.anandtech.com/show/5729/western-digital-velociraptor-1tb-wd1000dhtz-review/2

הארד דיסקים רגילים זה בסביבות ה-1 מגה.

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

לגבי האפסים:

תמהני. מאד.

http://en.wikipedia.org/wiki/Sparse_file

כבר EMULE ידע והשתמש בזה.

גם יוטטורנט יודע וניתן להגדיר ולהשתמש בזה.!

נסו לשנות. (אני לא חושב שזה יעזור ושיש קשר לבעיה המקורית. ).

בוא נעשה סדר.

את הבעיה המקורית צריך להפריד לשתי בעיות:

1. Disk Overloaded מופיע בכל מיני זמנים לאורך כל ההורדה.

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

הפתרון הוא לנסות לשחק עם גודל ה-cache או לחזור לגרסאות ישנות יותר.

2. Disk Overloaded מופיע בתחילת ההורדה של קובץ גדול.

הבעיה רלוונטית להרבה מאוד גרסאות אחורה.

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

בשביל בעיות כאלה בדיוק, הומצא הקונספט של Sparse Files. לפי מספר דיונים בפורומים של מיוטורנט, אפשר לראות שהמפתחים מכירים את הקונספט טוב מאוד, אבל מסתייגים ממנו בגלל שהוא גורם לפרגמנטציה מוגברת, כמו ש-House M.D הסביר. לכן הם הוסיפו את האופציה כ-advanced feature כבוי בדיפולט.

כשהדלקתי את האופציה אצלי עכשיו, מיד היה ניתן להבחין שהכונן הפסיק לטחון בתחילת ההורדה, מה שאכן פותר לחלוטין את בעיה מספר 2. אבל, הפרגמנטציה המוגברת שכנראה תקרה תפגע במהירות הגישה ל-HDD, מה שיגדיל את הסיכויים להיתקל בבעיה מספר 1 ויפגע בביצועים בכלליות. לכן אפשור ה-Sparse Files אינו מומלץ על הארד-דיסקים (HDDs).

עם זאת, על SSD המצב הפוך לחלוטין. אין שום משמעות פרקטית לפרגמנטציה על SSD, ולכן החיסרון היחיד של Sparse Files אינו רלוונטי. כמו-כן, יש יתרון נוסף: ללא Sparse Files, הקובץ נכתב תחילה עם אפסים ואח"כ נדרס עם המידע האמיתי, ולכן כל קובץ שיורד גורם לכתיבה כפולה על הכונן. עם Sparse Files, הקובץ ייכתב רק פעם אחת, כאשר המידע מגיע מהרשת, וכך חסכנו כתיבות יקרות ל-SSD. לכן נראה שאפשור ה-Sparse Files דווקא כן מומלץ על SSD-ים, מסיבות שאינן קשורות בכלל ל-Disk Overloaded (וגם, על SSD מלכתחילה היה נדיר להיתקל בבעיית Disk Overloaded...).

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