Проблемът на повечето хора е че първо че са някакви овце които смилат каквото им кажат без капка критично мислене. И второ, че после имат склонност да го преразказват със самочувствието на компетентни без да се уверят сами.

Тука си много ама много прав! Съгласен!

Ами ако не бях погледнал и следователно да питам за този въпрос, нямаше да разбера, че е така фрагментиран. Забавяне и да има, не е голямо. Който не му се занимава - здраве да е. Това обаче с FAT32 не е така.

Забавянето може и да не е голямо, но това че го държиш целия "в червено" НЕ е здравословно за харда. Според мен задължително си е дефрагментирането.

Обаче темата е ФАТ - НТФС и според ме н е крайно време да спрем да коментираме неща и изказвания които не са по темата!

Браво на Melmak ® - темата тъкмо тръгваше към затваряне!

Е, то и сийдването не е здравословно, както и играенето на игри, искащи голямо количество рам, както и още стотици операции.

Ето един тест за скоростите на копиране.

http://benchmarkfs.hit.bg/

Една сравнителна таблица между FAT и NTFS.

http://www.ntfs.com/ntfs_vs_fat.htm

Редактирано 20 април 200620 г. от Melmak ® (преглед на промените)

Ако говорим за стабилност - NTFS. Няма проблеми с кръстосани клъстъри, както при FAT С NTFS съм от 6 г. Още преди появата на ХР.Но до сега не съм загубил и бит информация. А при FAT ми се е случвало.

По рано проблема беше, че трудно се спасяваше информацията. Сега, след появата на ХР, вече не е проблем

А някой може ли да ми обясни защо NTFS, като е журнална файлова система се фрагментира?

Не ми скачайте сега на бой, моля. Не се заяждам. Просто питам, защото нямам дълбоки познания по файловите системи.

И бих се радвал някой да ми обясни защо Уиндоуските файлови системи се фрагментират, а Линуксските не.

ПС: И сега не ми обяснявайте, че и Линуксските файлови системи се фрагментирали. Знам това. То се получава само при напълване на дяла над 90%, а след това (ако се поизпразни), далът сам се дефрагментира.

Редактирано 21 април 200620 г. от loxs (преглед на промените)

Това е точният въпрос,който тормози и мен.Или по-точно казано: Как при линукските системи фрагментацията е намалена? На какво разчитат?

Ще взема да се разровя - дано разбера нещо повече.Единствено съм убеден е че това няма нищо общо с журналите.

Това е точният въпрос,който тормози и мен.Или по-точно казано: Как при линукските системи фрагментацията е намалена? На какво разчитат?

Ще взема да се разровя - дано разбера нещо повече.Единствено съм убеден е че това няма нищо общо с журналите.

Ами аз нито знам защо нито знаех до този момент и че линукските файлови с-ми не се фрагментират, но близко е до ума човек да си го обясни. Просто при Линукс, когато се записва даден файл и той не може да се побере в един фрагмент се извършва преразпределение на свободното и запълнено място В РЕАЛНО ВРЕМЕ, така че да не се получава. Може и да бъркам, но това трябва да е.

Ако е така, значи е спорно дали липсата на фрагментация у линукските ф. с-ми е + или -

Прави се компромис между бързина на машината попринцип или бързина в частен случай при записване на файл. В един случай е + в друг -

Просто при Линукс, когато се записва даден файл и той не може да се побере в един фрагмент се извършва преразпределение на свободното и запълнено място В РЕАЛНО ВРЕМЕ, така че да не се получава. Може и да бъркам, но това трябва да е.

Аха, това би пречило доста, на тая логика една по-яка дискова активност и системата ще забие. Не го вярвам. Не може да преразпределя в реално време.

Аха, това би пречило доста, на тая логика една по-яка дискова активност и системата ще забие. Не го вярвам. Не може да преразпределя в реално време.

Ами тогава записваните файлове се подреждат плътно един до друг, така че да няма възможност за фрагментация, но това също води до забавен запис.

Примерно при местене на някой файл в Уин той не се мести физически, а само се записва пътя на новото му местонахождение и това спестява чакането. Ако се местеше наистина с тия гигантски хардове, то би отнело страшно много време, веднъж да копира и след това да затрие предното.

Пак са относителни плюсовете и минусите :bye:

Edit: Сега ми дойде на акъла, че и да ги записва плътно пак ще се получава фрагментация, когато се затриват файловете та въпросното преразпределение може да става НЕ в реално, а при ШЪТ ДАУН ИЛИ СТАРТИРАНЕ (по-вероятно първото)

Редактирано 22 април 200620 г. от GFreeman (преглед на промените)

Ами тогава записваните файлове се подреждат плътно един до друг, така че да няма възможност за фрагментация, но това също води до забавен запис.

Примерно при местене на някой файл в Уин той не се мести физически, а само се записва пътя на новото му местонахождение и това спестява чакането. Ако се местеше наистина с тия гигантски хардове, то би отнело страшно много време, веднъж да копира и след това да затрие предното.

Пак са относителни плюсовете и минусите :bye:

Edit: Сега ми дойде на акъла, че и да ги записва плътно пак ще се получава фрагментация, когато се затриват файловете та въпросното преразпределение може да става НЕ в реално, а при ШЪТ ДАУН ИЛИ СТАРТИРАНЕ (по-вероятно първото)

Тогава пък едночасов ShutDown не би било приятно. И това не е

Тогава пък едночасов ShutDown не би било приятно. И това не е

Ох и аз не знам, но според мене все някога (дали в реално време или не) трябва да става това преразпределение.

Иначе как?

Абе дайте да разберем как се получава така, че ми стана много интересно и сега няма да мога да заспя от неизвестност и нетърпение. Пък и тва е Линукс - отворен код. Как са я правили няма да е някоя фирмена тайна. Лесно ще да е да се разбере.

Требе се пита някъде.

Редактирано 22 април 200620 г. от GFreeman (преглед на промените)

Мисля, че работата като обикновен потребител с нищо нямаше да промени ситуацията. При NT-базираните системи всеки процес разполага с определени ресурси, заделени му от ядрото на ОС и може да бъде прекъснат от ядрото, независимо от правата на потребителя, който го е стартирал. След като въпросният процес води до срив, това означава, че контролиращите привилегиите процеси, изпълнявани от ядрото на ОС в kernel 0 също са спрели да се изпълняват. И резултатът ще е същият.

Това е абсолютно погрешно схващане. Преди всичко, върни се пак на това, което ти написах за работата като администрато или обикновен потребител. Ако беше работил като обикновен потребител, системата ти нямаше и да усети, че има вирус, защото независимо, дали вируса се е заредил в паметта, той ще може да се разпространи само в директории и файлове, върху които ти имаш права за писане. Обикновените потребители нямат права за писане в системните директории. Така че, след като рестартираше PC-то, влезнеше в Safe mode и стартираше антивирусната, проблемът щеше да бъде отстранен без каквито и да е проблеми. Нещо да кажеш по този въпрос?

На пръв поглед твърдението ти звучи логично. Само че я се замисли КОГА става заразяването с вирус ? Тук имам предвид потребител като нас, а не ламер, който клика весело на всеки mail, обещаващ му голи снимки на Памела Андерсън. Отговорът е - единствено при инсталиране на нова програма. А инсталирането на нови програми не може да бъде извършено без административни права. Така че в крайна сметка пак се заразява цялата система.

Наистина ли ? Искам тогава да видя как ще влезеш като потребител с ограничени права, ще си пуснеш програма, заразена с вируса MS Blast и ще прекратиш процеса преди компютърът ти да се е рестартирал

Теоретично наистина би трябвало един Win XP НИКОГА да не забива, ако работиш по този начин. Само че това се отнася за някаква идеална ОС без грешки в ядрото си, без възможности за препълване на буферите и създаване на експлойти. А докато работим с реални операционни системи е по-добре да очакваме от тях най-лошото и предварително да вземем мерки за минимизиране на загубите. За мене една от тези мерки е използването на FAT32 и никога на NTFS за системните дялове. Както твърди "Пътеводител на галактическия стопаджия", разликата между нещата които могат да се развалят и тези, които не могат, се състои в това, че когато се развалят, вторите обикновено не могат да се поправят. Едно правило, с което съм 100% съгласен и намирам за раумно да спазвам

За MSBLAST ще кажа само,че,стига да си магиосник на клавиатурата по бързо писане (каквито има много),спокойно можеш да прекратиш процеса,правил съм го много пъти.SP2 го блокира и отдавна не е актуален,ама все пак.

До сега не ми се е случвало Win XP или 2003 да искат да се дефрагментират.Но това че много хора по навик от 98 и 95 си дефрагментират постоянно компютрите си е тяхно решение.При новите хардове това не променя скороста на четене и писане.

(Някой да не се засегне сега)

физически погледнато FAT NTFS EXT2 имат еднаква скорост на достъп спрямо оборотите на диска.

Кеша е в 98% за запис, относно фрагментирането, получава се при триене и записване на нови фаилове на секторите кадето е било трито. При Линукс SWAP фаила е отделен партишън за разлика от Windows каде то е в определен от потребителя (по подразбиране С партишън, кадето тои е с променлив размер за пестене на място. (препоръчително е да го на правите фиксиран с размер 1.5-2 пъти по голям от размера на физическта RAM памет)

Относно разликата на запис на данни върху различните фаилови с-ми unicode функцията на NTFS позволява имента на фаиловете да са на различни езици (латиница, кирилица,яроглифи и т.н.)

което при фат изисква зареждането на допълнителен драйвер (пример: дискета с файлове именовани на кирилица под 95 или 98 не винаги се четат под NT и обратното дискетите са под FAT12)

ПС: И сега не ми обяснявайте, че и Линуксските файлови системи се фрагментирали. Знам това. То се получава само при напълване на дяла над 90%, а след това (ако се поизпразни), далът сам се дефрагментира.

като ти стигне запълването на 40% ще се влачи като костенурка защото ще обикаля харда все едно е дали е с фрагментирани или разпръснати фаилове

фаиловите сървъри под коя да е фаилова система се дефрагментират често

а кои повече, тук рекламата играе роля, все пак под линукс приложенията се броят на пръсти

До сега не ми се е случвало Win XP или 2003 да искат да се дефрагментират.Но това че много хора по навик от 98 и 95 си дефрагментират постоянно компютрите си е тяхно решение.При новите хардове това не променя скороста на четене и писане.

(Някой да не се засегне сега)

не очакваи съобщение от рода "dear XP or 2003 user please defragment your hard drive for optimum performance" щото няма такова дефрагментираи и виж разликата

Редактирано 23 април 200620 г. от saentist (преглед на промените)

saentist не очаквам такова съобщение,но има преди да пуснеш дефрагмент да се даде да анализира преди това.Точно там го дава това съобщение че няма нужда от дефрагмент.Май ти пролича колко си чел какво съобщение ти изкарва.

А това за влаченето като се напълни хард диска трябва да си го сънувал някъде.Ако беше разбрал какво е журнална файлова система нямаше да пишеш такива неща.Същото е с дефрагментираните сървъри.Вземи задай този въпрос тук на админите ,кога си дефрагментират сървъра.

Защо ли имам чувството че повечето от мненията който даваш са сбор от суеверия и неща чути от някъде и звучащи много добре?

С здраве и успех с дефрагментирането.

като ти стигне запълването на 40% ще се влачи като костенурка защото ще обикаля харда все едно е дали е с фрагментирани или разпръснати фаилове

Позволи ми да се усъмня.Когато между файловете има празни места,това няма да доведе до забележим спад на производителността.Когато обаче самите файлове са на "парчета" главите трябва да се позиционират всеки път.

saentist не очаквам такова съобщение,но има преди да пуснеш дефрагмент да се даде да анализира преди това.Точно там го дава това съобщение че няма нужда от дефрагмент.Май ти пролича колко си чел какво съобщение ти изкарва.

А това за влаченето като се напълни хард диска трябва да си го сънувал някъде.Ако беше разбрал какво е журнална файлова система нямаше да пишеш такива неща.

При НТФС (а може би и при фат),наистина не би трябвало да се усеща това влачене.Със сигурност не е все едно дали има 10 файла или 100 000.Но всичко това по никой начин не касае журнала! Още не мога да си обясня защо някой хора свързват всичко с този журнал! Единственото негово предназначение е да ускори проверката на диска при неочаквано спиране на компютъра,или да покаже кой файлове са били засегнати.Останалото зависи от начина на организиране на данните върху диска.

Редактирано 23 април 200620 г. от Melmak ® (преглед на промените)

От толкова много постове вече се обърках.

Фрагментират ли се линукските файлови с-ми по-малко от уиндоуските или не?

Доколко размера на свободното място както и фрагментацията влияят на производителността при различните файлови с-ми?

Редактирано 23 април 200620 г. от GFreeman (преглед на промените)

Ох и аз не знам, но според мене все някога (дали в реално време или не) трябва да става това преразпределение.

Иначе как?

Абе дайте да разберем как се получава така, че ми стана много интересно и сега няма да мога да заспя от неизвестност и нетърпение. Пък и тва е Линукс - отворен код. Как са я правили няма да е някоя фирмена тайна. Лесно ще да е да се разбере.

Требе се пита някъде.

Windows XP например пренарежда когато компютъра е в Idle режим.

След толкова много теория, от която да си призная не разбирам твърде много, мога ли да попитам, защо след като си инсталирах на фосилния си компютър горепосочената система, нямам вече никакви проблеми и компютърът си работи като пушка? Преди това с Милениум и фат си беше пълен кошмар.

Не знам какво точно имаш в предвид, но FAT понякога е бавен заради силна фрагментация на файловоете. И при по-бавна машина и диск, резулалтът е ясен.

А някой може ли да ми обясни защо NTFS, като е журнална файлова система се фрагментира?

Не ми скачайте сега на бой, моля. Не се заяждам. Просто питам, защото нямам дълбоки познания по файловите системи.

И бих се радвал някой да ми обясни защо Уиндоуските файлови системи се фрагментират, а Линуксските не.

ПС: И сега не ми обяснявайте, че и Линуксските файлови системи се фрагментирали. Знам това. То се получава само при напълване на дяла над 90%, а след това (ако се поизпразни), далът сам се дефрагментира.

Ами ако не триеш файлове май няма да се фрагментира толкова.

Редактирано 23 април 200620 г. от Ned_Drag (преглед на промените)

Дефрагментацията с вградените Windows-инструменти на FAT32 е ужас. Зацепва на 10% и от там нататък часове. Ужас. Затуй масово сменяха програмите за дефрагментация - VoptXP например е идеална за фат; дискийпър той също зацепва на 10%. Под NTFS дефрагментацията с вградения Windows Defragmenter е доста по-гъвкав процес.

Под NTFS дефрагментацията с вградения Windows Defragmenter е доста по-гъвкав процес.

При което никога не завършва докрай.Тоест продължава докато мс решат че му стига толкова,като естествено вие нямате думата.Като се добави и че свапа е болкиран се получава шедьовър.

Сигурен ли си че дефрагментира в idle режим? Това обяснява абнормалната активност на диска която забелязах напоследък.Във всеки случай това е грозен метод да прикрият проблема,особено като се отчете липсата на възможност за изключване и ГБ който се навъртат на диска.

Както каза едино извънземно в СтарТрек "Very ugly,very ugly!".

Почти съм сигурен. Когато мръдна мишката - след няколко сек спира активноста на диска. Отделно има програми (Tweak) които могат да изключат тази опция.

От толкова много постове вече се обърках.

Фрагментират ли се линукските файлови с-ми по-малко от уиндоуските или не?

Доколко размера на свободното място както и фрагментацията влияят на производителността при различните файлови с-ми?

От толкова много постове,стана ясно,че абсолютно никой не е провел качествен тест на файловите системи.Всичко се базира предимно на слухове,главно от МС (поне за фат и нтфс).

Размера на свободното място е препоръчително да е 20 % или до 80% от диска да е зает.Доколкото прочетох при ext2,докато е спазено това фрагментацията на файловете се поддържа по-ниска.Няма пряка връзка с производителността.Правя известен паралел с уиндоуските фс по лично наблюдение.

Линукските системи като че ли се фрагментират по-малко и със сигурност имат повече и по-добри сравнителни тестове (но не и с фат,да не говорим за нтфс).

Производителността е още по-спорен фактор и изисква специализирани програми за да бъде измерена.

Не може да се каже дали най-бързата,най-добре подредената,най-сигурната или тази която използва най-малко процесора е най-добрата.

saentist не очаквам такова съобщение,но има преди да пуснеш дефрагмент да се даде да анализира преди това.Точно там го дава това съобщение че няма нужда от дефрагмент.Май ти пролича колко си чел какво съобщение ти изкарва.

А това за влаченето като се напълни хард диска трябва да си го сънувал някъде.Ако беше разбрал какво е журнална файлова система нямаше да пишеш такива неща.Същото е с дефрагментираните сървъри.Вземи задай този въпрос тук на админите ,кога си дефрагментират сървъра.

Защо ли имам чувството че повечето от мненията който даваш са сбор от суеверия и неща чути от някъде и звучащи много добре?

С здраве и успех с дефрагментирането.

Аз съм на принципа "ръка да пипне, око да види"

много мои приятели реваха от EXT2 на рутъри и сървъри когато спираше тока, при NTFS няма такова нещо MFT се грижи стриктно за фаиловата информация

Личния ми избор за дефрагментиране има и вариант за Линукс

СРАВНИТЕЛНА ТАБЛИЦА NTFS vs FAT

Редактирано 23 април 200620 г. от saentist (преглед на промените)

Понякога показва, че има нужда от дефрагмент. Както и да е.

Аз съм решил да не дефрагментирам до момента, в който стане наистина много червено при анализа. Тогава ще засека някои тежки приложения които имам времето за което се зареждат и как вървят. После дефрагмент и ще сравня и следователно споделя с вас резултатите в точни цифри. Така че - ако след няколко седмици темата е заключена - мислете му!!! Умната!