| 1.1, fresco (??), 16:36, 11/12/2007 [ответить]
| +/– |
Ну, это было понятно давно -- исходя из логики работы аллокатора reiserfs.
| | |
| 1.2, Moralez (??), 17:10, 11/12/2007 [ответить]
| +/– |
на самом деле, если верить рассылке freebsd-stable@, если файл нефрагментированный, то это не значит что он одним куском на диске лежит. если я правильно понял %-) так что, в реальности фрагментация - не показатель. Даже если она равна нулю, всё-равно файлы не лежат штабелями. я с тех пор на этот показатель внимания не обращаю, т.к. он нерепрезентативен... :(
| | |
| |
| 2.3, fresco (??), 18:31, 11/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
Не правильно. Презентативен, обращают. Фрагментация просто разная бывает.
| | |
| |
| 3.4, Tracer (??), 00:07, 12/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
Да-да! Бывает Фрагментированно, но так, что недеврагментированно! %)))) Сам видел!!! =))))
| | |
|
| 2.6, serg1224 (?), 04:00, 12/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
 >если файл нефрагментированный, то это не значит что он одним куском на диске лежит
Дефрагментация хороша уже тем, что "куски" рядом лежат, последовательно друг за другом. Упреждающее чтение даст повышение производительности (HDD придется меньше головками двигать).
Дефрагментированные файлы проще найти и восстановить после аварийного сбоя, если нет бэкапа, конечно.
Кстати, если фрагменты файлов записывать попеременно на разные стороны (блины) жесткого диска, то можно добиться параллельной работы нескольких головок.
| | |
| |
| 3.9, nuclight (?), 16:42, 12/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
 Это не всё не столь актуально в нынешних файловых системах (с другим расположением инод и прочих метаданных), особенно в условиях многозадачности и наличия кэшей. Более того, есть и практики намеренного фрагментирования файлов для общего ускорения в конечном счете - навроде этой самой записи на разные блины, но не такое - потому что реальная геометрия винтов уже давно оторвана от той, которую видит ОС.
| | |
|
|
| 1.5, pavlinux (??), 00:08, 12/12/2007 [ответить]
| +/– |
 ... Нужна, нужна... и обязательно с красивыми мигающими квадратиками, ala O&O Defrag :)
| | |
| 1.7, uldus (ok), 10:30, 12/12/2007 [ответить]
| +/– |
Я бы еще отметил, что сам факт фрагментации начинает появляться при недостатке свободного места на диске, если процентов 20% свободно, то и беспокоиться не о чем. Серьёзно задуматься о чистке нужно, когда в логе появятся сообщения о изменении политики оптимизации с "time" на "space".
| | |
| 1.8, Дмитрий ю. Карпов (?), 11:42, 12/12/2007 [ответить]
| +/– |
Например, для запускаемых файлов (которые практически никогда не меняются) оптимальна "плотная укладка", когда не резервируется место под возможное расширение файла. Так что /usr надо дефрагментировать одним способом, а /var надо дефрагментировать совершенно иначе. У Norton SpeedDisk была возможность выбора алгоритма/цели дефрагментации вплоть до "собрать директории вместе (для ускорения поиска файлов по имени)".
| | |
|
