1) диски просто большой емкости 2 Тб и более на диск
2) диски нормальной емкости — 0,5 Тб — 2 Тб
3) микроскопические диски — мнее 0,5 Тб.
Расти емкости так не будут быстро — наводнение привело к скачку цен, а это снизило покупательскую способность. Боюсь в технологиях также наступит "стагнация".
Очень и очень с Вами соглашусь... Не только ext4, но и поддержку других ФС надо подключать... Ведь таже xfs предназначена для работы с большими файлами (видеозаписи) и очень прекрасно с этим справляется...
Все Достижения в духе майкрософт — 15-ти летняя багнутая на фрагментации ФС оказывается самая развитая, вместо того чтобы починить фрагментацию ее теперь автоматически лечат!
Наложили кучу заплаток и это величайшее достижение, кушайте хомячки.
NTFS — очень экономная система. Размер кластеров в ней разумно минимален — обычно это 4 кб . Как известно, система сильнее всего фрагментирует файлы, когда свободное место кончается, когда приходится использовать мелкие дырки, оставшиеся от других файлов. Тут возникает первое свойство NTFS, которое прямо способствует серьезной фрагментации.
Диск NTFS поделен на две зоны. В начале диска идет MFT зона — зона, куда растет MFT, Master File Table. Зона занимает минимум 12% диска, и запись данных в эту зону невозможна. Это сделано для того, чтобы не фрагментировался хотя бы MFT. Но когда весь остальной диск заполняется — зона сокращается ровно в два раза. И так далее. Таким образом, мы имеем не один заход окончания диска, а несколько. В результате если NTFS работает при диске, заполненном на около 90% — фрагментация растет как бешенная.
Попутное следствие — диск, заполненный более чем на 88%, дефрагментировать почти невозможно — даже API дефрагментации не может перемещать данные в MFT зону. Может оказаться так, что у нас не будет свободного места для маневра.
Далее. NTFS работает себе и работает, и всё-таки фрагментируется. Этому способствует странный алгоритм нахождения свободного места — второе серьезное упущение. Если файл пишется большими кусками — всё нормально. Но если файл медленно растет — алгоритм такой: берется какой-то определенный объем диска и заполняется файлом до упора. Причем по очень интересному алгоритму: сначала заполняются большие дырки, потом маленькие. Т.е. типичное распределение фрагментов файла по размеру на фрагментированной NTFS выглядит так (размеры фрагментов):
Так процесс идет до самых мелких дырок в 1 кластер, несмотря на то, что на диске наверняка есть и гораздо более большие куски свободного места... Что, естественно, способствует большей фрагментации.
В NT существует стандартная API дефрагментация. Обладающая интересным ограничением для перемещения блоков файлов: за один раз можно перемещать не менее 16 кластеров , причем начинаться эти кластеры должны с позиции, кратной 16 кластерам в файле. В общем, операция осуществляется исключительно по 16 кластеров. Следствия:
В дырку свободного места менее 16 кластеров нельзя ничего переместить (кроме сжатых файлов, но это тонкости).
Файл, будучи перемещенный в друге место, оставляет после себя «временно занятое место», дополняющее его по размеру до кратности 16 кластерам.
При попытке некоректно («не кратно 16») переместить файл, результат часто непредсказуем. Что-то округляется, что-то просто не перемещается. Тем не менее, всё место действия щедро рассыпается «временно занятым местом». Наверное, о нас заботятся, чтобы мы отстали от этого места — чтобы алгоритм дефрагментации не клинило.
«Временно занятое место» освобождается через некоторое время, обычно где-то пол минуты. Гы.
Тем не менее, логично было бы использовать это API. Его и используют. Поэтому процесс стандартной дефрагментации, с поправками на ограниченность API, идет следующими фазами, не обязательно в этом порядке:
Вынимание файлов из MFT зоны. Не специально — просто обратно туда их положить не представляется возможным. Безобидная фаза, и даже в чем-то полезная.
Дефрагментация файлов. Безусловно, полезный процесс, несколько правда осложняемый ограничениями кратности перемещений — файлы часто приходится перекладывать сильнее, чем это было бы логично сделать по уму.
Дефрагментация MFT, виртуалки ( pagefile.sys ) и каталогов. Возможна через API только в Windows2000, иначе — при перезагрузке, отдельным процессом, как в Diskeeper-е.
Складывание файлов ближе к началу — так называемая дефрагментация свободного места. Вот это — воистину страшный процесс…
Допустим, мы хотим положить файлы подряд в начало диска. Кладем один файл. Он оставляет хвост занятости дополнения до кратности 16. Кладем следующий — после хвоста, естественно. Через некоторое время, по освобождению хвоста, имеем дырку
читайте больше ЖЁЛТОЙ прессы — структура MFT фиксированная — т.е на все записи о файлах выделено одинаковое место на дисках, из этого следует , что MFT никак не может быть фрагментирован
Это проповедь "копипастера" о том, что "мелкомягкие" ничего не умеют делать нормально. Он описал минусы использования мелких файлов(что присуще всем фс), придумал какой то новый механизм выделения места под записи и абсолютно случайно не указал ни одного плюса ntfs, к чему бы это?
а особых плюсов у нтфс нету, только если по сравнению с фат32, а в остальном устаревшая чрезмерно фрагментируемая ФС, котрую давно пора ( и это предпологалось при выходе еще вислы) заменить. НО, индусом видать не по зубам.
да о чём статья понятно, а вот смысл в 7,8, возможно, 9 и т.д. в чём? если прекрасно можно работать и отдыхать на хрюше, большие диски? накой? накой х держать архив с фильмами в BR формате, если можно скачать, посмотреть и стереть, захотелось — снова скачал, посмотрел и стёр
предлагаю с таким подходом к жизни уйти с работы, переселится в коробку из-под холодильника и ходить по ветру на улицу, подтираться лопухом. а накой все эти большие квартиры, деньги и туалетная бумага. захотелось — к помойке подошел (скачал) выпил и ок
Wındows8 последняя, или предпоследняя система, которая будет загружаться. Думаю процесс инсталяции в будущем будет напоминать сегодняшнюю загрузку приложения в память. А включение компьютера и запуск приложения будут происходит в течении секунд и долей секунд соответственно.
Почему я так думаю: 1. есть уже несколько интересных инноваций которые сотрут понятие памяти и долговременной памяти. Представьте, что ваша система записана на флешке обладающей скоростью чтения записи соответствующей скорости ... оперативной памяти. Режим гибернации не нужен — т.к. все всегда лежит в памяти. Гибернация будет нужна скорее для консервации общения с внешними устройствами.
2. Произошло воистину великое событие. Лицензирования софта для виртулизации на ядро отменено. Вместо этого введена система лицензирования на единицу объема памяти. А это означает, что НАКОНЕЦТО производители софта начнут оптимизировать код и всякие монстрообразные приложения размером в сотни мегабайт (за исключением может разве игрушек или САПРов) канут в лету.
Если сложить два эти фактора с законом мура то можно легко представить, что вы будете ходить с флешкой на которой находиться вся ваша операционка, со всем софтом.
Да нет, я считаю SergGGG прав, несогласен с ним только в двух вещах, 2 пункт он явно переоценил, и ВАШУ операционку не надо будет носить на флешке, она просто будет подгружаться из сети в любом месте откуда бы вы не вошли в сеть. А если быть точнее то не сама операционка будет подгружаться а ваши индивидуальные натсройки и ваши файлы, также уйдет в сеть большинство офисного софта MS Office 1С для примера, конечно большие компании врядли уйдут в облако но маленькие и средние точно уйдут, вопрос лишь во времени, я думаю на это уйдет не более 10 лет.
Скорее всего на флешке будут только файлы данных, а операционная система будет на сервере очередного поколения интернета. В общем, всё идет именно к этому. Что, кстати, подорвёт пиратство — придётся взламывать доступ к удалённым сервисам, а не взламывать программы.
все — приехали теперь вместо ведерочка будет ведрище — вместо Bios — Uefi, вместо компьютерного интерфейса планшетник, а вместо одного ядра 50 маленьких (в сумме равных этому одному — А ВКЛЮЧАЕШЬ НИ ХРЕНА НЕ РАБОТАЕТ
Комментарии
1) диски просто большой емкости 2 Тб и более на диск
2) диски нормальной емкости — 0,5 Тб — 2 Тб
3) микроскопические диски — мнее 0,5 Тб.
Расти емкости так не будут быстро — наводнение привело к скачку цен, а это снизило покупательскую способность. Боюсь в технологиях также наступит "стагнация".
А вин 3,11 на 468дх100 просто летала ?
Наложили кучу заплаток и это величайшее достижение, кушайте хомячки.
Диск NTFS поделен на две зоны. В начале диска идет MFT зона — зона, куда растет MFT, Master File Table. Зона занимает минимум 12% диска, и запись данных в эту зону невозможна. Это сделано для того, чтобы не фрагментировался хотя бы MFT. Но когда весь остальной диск заполняется — зона сокращается ровно в два раза. И так далее. Таким образом, мы имеем не один заход окончания диска, а несколько. В результате если NTFS работает при диске, заполненном на около 90% — фрагментация растет как бешенная.
Попутное следствие — диск, заполненный более чем на 88%, дефрагментировать почти невозможно — даже API дефрагментации не может перемещать данные в MFT зону. Может оказаться так, что у нас не будет свободного места для маневра.
Далее. NTFS работает себе и работает, и всё-таки фрагментируется. Этому способствует странный алгоритм нахождения свободного места — второе серьезное упущение. Если файл пишется большими кусками — всё нормально. Но если файл медленно растет — алгоритм такой: берется какой-то определенный объем диска и заполняется файлом до упора. Причем по очень интересному алгоритму: сначала заполняются большие дырки, потом маленькие. Т.е. типичное распределение фрагментов файла по размеру на фрагментированной NTFS выглядит так (размеры фрагментов):
16 — 16 — 16 — 16 — 16 — [скачек назад] — 15 — 15 — 15 — [назад] — 14 — 14 — 14 … 1 — 1 — 1 -1 — 1…
Так процесс идет до самых мелких дырок в 1 кластер, несмотря на то, что на диске наверняка есть и гораздо более большие куски свободного места... Что, естественно, способствует большей фрагментации.
В NT существует стандартная API дефрагментация. Обладающая интересным ограничением для перемещения блоков файлов: за один раз можно перемещать не менее 16 кластеров , причем начинаться эти кластеры должны с позиции, кратной 16 кластерам в файле. В общем, операция осуществляется исключительно по 16 кластеров. Следствия:
В дырку свободного места менее 16 кластеров нельзя ничего переместить (кроме сжатых файлов, но это тонкости).
Файл, будучи перемещенный в друге место, оставляет после себя «временно занятое место», дополняющее его по размеру до кратности 16 кластерам.
При попытке некоректно («не кратно 16») переместить файл, результат часто непредсказуем. Что-то округляется, что-то просто не перемещается. Тем не менее, всё место действия щедро рассыпается «временно занятым местом». Наверное, о нас заботятся, чтобы мы отстали от этого места — чтобы алгоритм дефрагментации не клинило.
«Временно занятое место» освобождается через некоторое время, обычно где-то пол минуты. Гы.
Тем не менее, логично было бы использовать это API. Его и используют. Поэтому процесс стандартной дефрагментации, с поправками на ограниченность API, идет следующими фазами, не обязательно в этом порядке:
Вынимание файлов из MFT зоны. Не специально — просто обратно туда их положить не представляется возможным. Безобидная фаза, и даже в чем-то полезная.
Дефрагментация файлов. Безусловно, полезный процесс, несколько правда осложняемый ограничениями кратности перемещений — файлы часто приходится перекладывать сильнее, чем это было бы логично сделать по уму.
Дефрагментация MFT, виртуалки ( pagefile.sys ) и каталогов. Возможна через API только в Windows2000, иначе — при перезагрузке, отдельным процессом, как в Diskeeper-е.
Складывание файлов ближе к началу — так называемая дефрагментация свободного места. Вот это — воистину страшный процесс…
Допустим, мы хотим положить файлы подряд в начало диска. Кладем один файл. Он оставляет хвост занятости дополнения до кратности 16. Кладем следующий — после хвоста, естественно. Через некоторое время, по освобождению хвоста, имеем дырку
Большинство файловых систем устроено по такому же принципу.
таже XP намного лучше 7 в плане инструментов.
Кстати это был решаюший аргумент , почему я так и не перешел с хрюнделя на гламур7е уё...ще.
Любопытно посчупать восьмёрку, пристрелили они предыдущего придурка дизайнера эргономиста?
а не о том как тебе ничего не нужно.
Рабочие данные храню только на своих фтп, мне для работы не поверите хватает 10гб на хостинге.
классно прокоментировал)))
Почему я так думаю: 1. есть уже несколько интересных инноваций которые сотрут понятие памяти и долговременной памяти. Представьте, что ваша система записана на флешке обладающей скоростью чтения записи соответствующей скорости ... оперативной памяти. Режим гибернации не нужен — т.к. все всегда лежит в памяти. Гибернация будет нужна скорее для консервации общения с внешними устройствами.
2. Произошло воистину великое событие. Лицензирования софта для виртулизации на ядро отменено. Вместо этого введена система лицензирования на единицу объема памяти. А это означает, что НАКОНЕЦТО производители софта начнут оптимизировать код и всякие монстрообразные приложения размером в сотни мегабайт (за исключением может разве игрушек или САПРов) канут в лету.
Если сложить два эти фактора с законом мура то можно легко представить, что вы будете ходить с флешкой на которой находиться вся ваша операционка, со всем софтом.