The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Заметили полезную информацию ? Пожалуйста добавьте в FAQ на WIKI.
. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..." +/
Сообщение от nagualemail (ok), 22-Сен-12, 10:12 
> Они вдруг удивительно сочетаются лишь до той поры пока это выгодно. А
> как только дружба начинает мешать выгоде - так сразу же вчерашний
> друг-союзник радостно пыряется кинжалом в спину, приговаривая что-то там про "Это
> просто бизнес, ничего личного!". Поэтому глядя на улыбчивые физиономии друзей-капиталистов
> не забывайте о том что они улыбаясь и дружа с удовольствием
> прокатят "ближнего своего" и пырнут в спину, если это сулит хоть
> какую-то прибыль. При том чем больше прибыль, тем беспринципнее капиталист прет
> по головам и трупам. Природа настоящего капиталиста такова.

Нет никакой необходимости записывать свои открытия в форуме.

> Да, я додумал: вы зациклены на *bsd и ZFS. И никак не
> можете понять, что архитектурно btrfs мало того что не слишком похож
> на zfs, так еще исправляет ряд его упущений и обладает рядом
> настроек которые в принципе позволят ему достаточно сухо и комфортно жить
> на весьма разных по своей природе накопителях.

Мы тут много обсуждали натройки zfs но ниразу не видели настроек btrfs ... странно.

> Мсье сообщает что файл может лежать непрерывно и при просто быстрой записи
> файла на незасранный том. Более того, качественно реализованный аллокатор активно стремиться
> добиться именно такого случая настолько насколько позволяют реалии свободного места на
> диске. Чем больше свободного места на диске и меньше фрагментировано свободное
> место, тем лучше это получается. В клиническом случае если мы резво
> пишем файл на только что созданную пустую ФС, он скорее всего
> будет выложен идеально линейно.

Последняя враза явная лож :))) как минимум для половины фс.

> Ну нихрена себе ламерство. А какие законы природы запрещают файлам лежать линейно
> на остальных ФС? Чисто теоретически, структуры большинства ФС это вполне допускают
> и приветствуют. Чисто практически - уж насколько получится. И даже мелкие
> неидеальности типа seek в сторону 1 раз на 100Мб мало чего
> меняют. Ну будет не 100% скорости а 99%, допустим. Никто и
> не заметит особой разницы. Фрагментация являет собой проблему когда том становится
> загажен и не удается выкроить непрерывный кусок.

Вы что то упустили в теории.


> Во первых, можно отдефрагать неудачно разложенный файл просто его копированием и удалением
> старого размазанного варианта, например. При этом используется свойство аллокатора пытаться
> разложить файл максимально линейно. Таким манером можно частично отдефрагментировать
> практически любую "классическую" ФС, как минимум для наиболее злободневных файлов. Лишь
> бы свободного места было много, иначе аллокатору негде будет развернуть деятельность
> по оптимизации и получится опа. Такое помогает от неудачно разместившихся файлов,
> если совсем опа в ФС еще не наступила. По поводу чего
> и не советуют тома забивать более чем на 70-90%. Иначе сильно
> фрагментируется свободное место и том коллапсирует. Что будет - отлично видно
> на примере изена, с его легендарными 6Мб/сек на шпиндель :)

Месье может назвать хоть одну фс в линуксе которая попадает под его критерий- практически любую "классическую" ?


> Во вторых, для ext4 дефрагер есть. С неких пор поставляется с остальными
> утилитками для файловой системы. Называется e4defrag. В свежих выпусках дистров обычно
> есть сразу.

Есть но до виндозного ему еще очень далеко :))

> В третьих, в случае CoW файловых систем обязан быть garbage collector разгребающий
> устаревшие неиспользуемые блоки. Иначе CoW логика просто забьет том до отказа.
> А раз он всяко есть и кантует блоки - пусть заодно
> и дефрагит в процессе! В btrfs этот достаточно очевидный факт до
> разработчиков дошел и там GC совмещен с дефрагером, по поводу чего
> у btrfs есть встроенный дефраг. В ZFS такого не было, да.
> Почему? Наверное потому что это одна из первых CoW ФС.

Палундра в ZFS нет дефрагментатора %)

> Не припоминаю такой фамилии.

Я почему то не ожидал другова ответа :-))

>Но мсье знает некоторые другие фамилии. Например, Ланау
> и Лившиц. Забавные дяденьки - спокойно считают в уме интегралы на
> 2 страницы и полагают что все остальные могут не хуже, поэтому
> просто не приводят подобные преобразования в своей книжке :).

И какая практическая польза от этой ментальной маструбации ?


> Это вы про ZFS. Не надо переносить его свойства на btrfs. Я
> его ради лулзов запускал на железке с 64Мб и хилым процом.
> Даже работало. Хотя ext4 показал себя несколько быстрее в такой конфигурации
> и меньше нагружал проц, что для мелкой железки актуально. А на
> типовом девайсе типа нотика с 2Гб оперативы оно себя будет чувствовать
> вполне по королевски. Оно в целом помедленнее ext4 (который вышел на
> удивление шустрым), но в последнее время основательно подтянули. Я ссылочку на
> недавние бенчи привел.

Оно себя будет чуствовать по королевски пока вы не запустите лису или что там у вас на ноуте, тоесть пока 2 гига памяти свободны и могут использоваться под кеш.

С счастью большинство читателей не станут тратить время на этот бред. В целом это называется калейдоскапический идиотизм. Диагноз гуглится.

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..., opennews, 19-Сен-12, 13:02  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру