בעיה באחסון קבצים גדולים על דיסק און קי - עמוד 2 - אמצעי אחסון - HWzone פורומים
עבור לתוכן
  • צור חשבון

בעיה באחסון קבצים גדולים על דיסק און קי

tomerA

נוצר על ידי tomerA
ב אמצעי אחסון

Recommended Posts

  • תגובות 38
  • נוצר
  • תגובה אחרונה
DOGMA Zone Master

DOGMA

פורסם
פורסם

תכנס לDevice Manager תחת הכוננים תמצא את הדיסק הנייד שלך, לחיצה ימנית Properties, תחת אחד הטאבים אמור להיות לך 2 אופציות Optimize for removal וOptimize for performance תחבר בשניה(Performance) לאחר מכן תוכל לפרמט את הכונן כNTFS.

יש סימה למה לא מאפשרת לפרמט כוננים לNTFS סתם ככה, זאת מערכת קבצים רגישה יחסית. מה שאומר שכיוון שNTFS בין השאר מתבססת על Transaction Journal הוצאה של הדיסק ללא "Eject" בSafely remove devices/לחיצה ימנית על האייקון שלו במחשב שלי תוביל ליצירה של שגיאות במערכת הקבצים, UBEים ואיבוד מידע אם זה נעשה בצורה שיגרתית.

קישור לתוכן
שתף באתרים אחרים
ag43 Zone Master

ag43

פורסם
פורסם

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

הקובץ שעבדת עליו (ולפעמים גם את כל מערכת הקבצים עצמה :P )

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

קישור לתוכן
שתף באתרים אחרים
DOGMA Zone Master

DOGMA

פורסם
פורסם

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

הקובץ שעבדת עליו (ולפעמים גם את כל מערכת הקבצים עצמה :P )

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

לא בדיוק, גם בFAT היה לך Journal אבל ברמת הFS DRIVER, זה למה אחרי כל "ריסט" היה לך check disk שאחד הדברים שהוא עשה זה להתאים את ה journal של מערכת הקבצים הלוגית לfile allocation table של מערכת הקבצים הפיזית.

בNTFS כל פעולה נרשמת בלוג, חוסר קונסיסטניות בלוג גורם לשגיעות של מערכת הקבצים ואיבוד מידע, מה עוד שFAT32 לא תומכת בDelayed Write מבחינת הדרייבר, ככה שזה מוריד את הסיכוי שאתה שולף קובץ שמבחינת מערכת ההפעלה "סיים" להכתב, אבל בפועל עדיין לא כתוב על הדיסק.

קישור לתוכן
שתף באתרים אחרים
KAKADU999 Zone Master

KAKADU999

פורסם
פורסם

^^^^^

בתכל'ס, הפסקת מתח באמצע " דופקת " את הכתיבה לדיסק,

וזה בלי להיכנס לרמות של ג'ורנל ושות'.

מפליא שבשלל השיפורים שמכניסים למערכות ההפעלה, לא פותרים את הבעיה

שמעלה פותח הדיון, נניח ע"י פיצול אוטומתי שיבוצע ע"י מ"ה עצמה, ללא צורך בתוכנות

צד שלישי, כאילו מה הבעיה ?

:xyxthumbs:

קישור לתוכן
שתף באתרים אחרים
ag43 Zone Master

ag43

פורסם
פורסם

לא בדיוק' date=' גם בFAT היה לך Journal אבל ברמת הFS DRIVER, זה למה אחרי כל "ריסט" היה לך check disk שאחד הדברים שהוא עשה זה להתאים את ה journal של מערכת הקבצים הלוגית לfile allocation table של מערכת הקבצים הפיזית.

בNTFS כל פעולה נרשמת בלוג, חוסר קונסיסטניות בלוג גורם לשגיעות של מערכת הקבצים ואיבוד מידע, מה עוד שFAT32 לא תומכת בDelayed Write מבחינת הדרייבר, ככה שזה מוריד את הסיכוי שאתה שולף קובץ שמבחינת מערכת ההפעלה "סיים" להכתב, אבל בפועל עדיין לא כתוב על הדיסק.

[/quote']

היתרון הגדול בלוג של הNTFS, שעקרונית לכל ביט שעובר ממקום למקום\נכתב פעם ראשונה יש "יומן" ששומר עליו, ואם יש חוסר עקיבות בנתונים

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

FOUND והמידע היה הולך לאיבוד. נשאל בצורה יותר פשוטה - מתי בפעם האחרונה הושחת לך קובץ שהיה בשימוש (של המשתמש או מערכת

ההפעלה) בהפסקת חשמל עם NTFS? עכשיו תשאל את עצמך אותה שאלה על הFAT.

קישור לתוכן
שתף באתרים אחרים
KAKADU999 Zone Master

KAKADU999

פורסם
פורסם

אבל כבר פתרו את הבעיה.

לפתרון קוראים ntfs או ext2/3/4 או עוד מספר שמות

בכל הצניעות ובמלא הרצינות - אני יודע את הפתרונות, וגם אתה יודע את הפתרונות

למה שהתלבטתי אם לקרוא לו " בעיה ".

אבל העובדה היא שכל פרק זמן צצות השאלות האלה, ורק תהיתי מה כ"כ קשה

לעשות את זה במ"ה.

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

:xyxthumbs:

קישור לתוכן
שתף באתרים אחרים
DOGMA Zone Master

DOGMA

פורסם
פורסם

בכל הצניעות ובמלא הרצינות - אני יודע את הפתרונות, וגם אתה יודע את הפתרונות

למה שהתלבטתי אם לקרוא לו " בעיה ".

אבל העובדה היא שכל פרק זמן צצות השאלות האלה, ורק תהיתי מה כ"כ קשה

לעשות את זה במ"ה.

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

:xyxthumbs:

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

היתרון הגדול בלוג של הNTFS, שעקרונית לכל ביט שעובר ממקום למקום\נכתב פעם ראשונה יש "יומן" ששומר עליו, ואם יש חוסר עקיבות בנתונים

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

FOUND והמידע היה הולך לאיבוד. נשאל בצורה יותר פשוטה - מתי בפעם האחרונה הושחת לך קובץ שהיה בשימוש (של המשתמש או מערכת

ההפעלה) בהפסקת חשמל עם NTFS? עכשיו תשאל את עצמך אותה שאלה על הFAT.

זה נע בין לא מדוייק ללא נכון :) בFAT יש 2 טבלאות של קבצים שמשמשות לשחזור במקרה של נפילה, בFAT עקרונית גם אין הגבלה לגודל קובץ עד ל2GBIT, רוב ההגבלות הן תוצאה של תוכנות הפרמוט של MS שהן דיי ביזיוניות, וגם שאר מערך התוכנה התומך היה על הפנים, מערכות קניוניות אחרות שמשתמשות בFAT אפילו לא 32 מתגברות הרבה יותר טוב על הבעיות שאתה טוען שיש כביכול, סה"כ זה היה עניין של כמה משאבים רצו להקצות לניהול מערכת הקבצים, וזה לא היה הרבה. בקשר למה שאמרת על NTFS זה רחוק מלהיות מדוייק, יש לוג טרנזקציות, מערכת ההפעלה לא בדיוק יודעת לחפש במקום הקודם, היא יודעת לשחזר את הMFT בעזרת המידע שנשמר ב $MFTmirr ו$Log_File, אם תנסה להעתיק קובץ ממקום למקום ותוציא את החשמל מהדיסק באמצע אל תצפה שהקובץ שלך יחזור למקום המקורי שלו, או תוכל להמשיך בפעולה ישר לאחר מכן(וכן יש מערכות קבצים שכן מאפשרות את זה). עכשיו בנוסף לזה יש את הUSN, שכן הוא מתאר כל דבר שנעשה אבל הוא איננו שומר מידע או את מהות השינוי עצמו. שמירה ברמה שאתה "מתאר" נקראת Sapshotting שבה כל שינוי מתבצע ללא שינוי המידע המקורי אלא על יצירת מידע חדש והחלפה ההפניות מבחינת מערכת הקבצים למיקום של המידע שנוסף או השתנה, תוך שמירת המפנים הישנים למידע שכביכול השתנה. NTFS תומך בזה תחת VSS.

קישור לתוכן
שתף באתרים אחרים

ארכיון

דיון זה הועבר לארכיון ולא ניתן להוסיף בו תגובות חדשות.

עבור לרשימת הדיונים
×
  • צור חדש...