LINUX.ORG.RU
Ответ на: комментарий от iZEN

>Следующий вброс: Oracle отказывается от разработок Btrfs и переводит Анбрикабл Linux на ZFSv22. :))

Так и запишем: Oracle купила Sun из-за ZFS. Правда с нагрузкой в виде MySQL и прочей фигни.

tommy ★★★★★
()
Ответ на: комментарий от iZEN

Изенька, а давай теперь ты приведешь такую же таблицу для Ext3.

P.S. Шо-то общение в новостном треде и еще луркание по околобздевым форумам привело меня к тому, что на свободный ноут будет поставлен OpenSolaris — соплярка сопляркой, но коммьюнити у нее... Посимпатичнее, что ли, чем у BSD любых мастей, и с объективной реальностью не испытывает проблем.

shimon ★★★★★
()
Ответ на: комментарий от dn2010

Словами линуксоида: «нету и не нужно, так как ОПАСНО». :))

iZEN ★★★★★
()
Ответ на: комментарий от shimon

11. Дикая фрагментация при интенсивной записи/стирании файлов
Ext3 — Да, из-за неиспользования неполностью занятых блоков и выделении непрерывного пространства
UFS2 — Нет, из-за использования фрагментов блоков в группах цилиндров

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

> 11. Дикая фрагментация при интенсивной записи/стирании файлов

Расскажи мне, как ощутить фрагментацию при работе с ФС.

shimon ★★★★★
()
Ответ на: комментарий от iZEN

И, да, что все-таки имеет перевес: мифическая фрагментация, которую у меня не был способен ощутить LVM2 на протяжении 4 лет использования, или журналирование, отсутствие которого способно превратить файлы на UFS2 в какашку?

shimon ★★★★★
()
Ответ на: комментарий от shimon

>Расскажи мне, как ощутить фрагментацию при работе с ФС.

У меня такое было на забитым под завязку винте с торрентами, помогло слить все(скорость была где-то метр в секуну) и залить взад. ext3

madcore ★★★★★
()
Ответ на: комментарий от iZEN

>11. Дикая фрагментация при интенсивной записи/стирании файлов Ext3 — Да, из-за неиспользования неполностью занятых блоков и выделении непрерывного пространства

Бугагец. Именно из-за выделения непрерывного пространства ее и меньше.

Использование неполностью занятых блоков от фрагментации той же торренто-помойки практически не спасет.

dikiy ★★☆☆☆
()
Ответ на: комментарий от shimon

> или журналирование, отсутствие которого способно превратить файлы на UFS2 в какашку?

Ты понимаешь, что ты сейчас слил?

iZEN ★★★★★
()
Ответ на: комментарий от dikiy

> Бугагец. Именно из-за выделения непрерывного пространства ее и меньше.

Угу, но есть нюансы.

Из-за выделения непрерывного пространства в последнем блоке с данными образуется малозаметное неиспользуемое пространство вследствие целого числа блоков, требуемого для хранения данных файлов. Например, на разделе размером 100ГБ и размере блока ФС 4кбайта образуются незаполненные блоки размером 0...3,99кбайта. Сколько файлов с размером не кратным размеру блока ФС — столько и незаполненных блоков. Теперь посчитай, сколько полезного пространства расходуется у тебя на Ext2/3 на такие вот не доконца заполненные блоки.

Когда на диске с Ext2/3 пишутся и стираются файлы, непрерывных отрезков с блоками становится всё меньше, и целые блоки для хранения данных новых файлов начинают выделяться в произвольных местах диска — на месте ранее стёртых файлов. Естественная фрагментация файлов растёт из-за малой «гранулярности» пространства носителя.

В UFS2 используется адресация фрагментов блоков, так что хранение данных осуществляется более экономично: во-первых, непрерывное пространство выделяется не только из целых незанятых блоков, но и из последовательности фрагментов не доконца занятых блоков; во-вторых, для больших файлов используются блоки переменного/увеличенного размера (максимум в 8 раз больше стандартного 16кбайт) — это ещё одна степень свободы политики размещения и уменьшения фрагментации.

iZEN ★★★★★
()
Ответ на: комментарий от shimon

>P.S. Шо-то общение в новостном треде и еще луркание по околобздевым форумам привело меня к тому, что на свободный ноут будет поставлен OpenSolaris — соплярка сопляркой, но коммьюнити у нее... Посимпатичнее, что ли, чем у BSD любых мастей, и с объективной реальностью не испытывает проблем.

Ты сначала попробуй в виртуалке. Думаю, ты быстро переменишь мнение.

linuxfan
()
Ответ на: комментарий от shimon

>> Ты понимаешь, что ты сейчас слил?

UFS2 умеет журналироваться? С каких пор?


Со вчерашнего дня прошлого года.

iZEN ★★★★★
()
Ответ на: комментарий от linuxfan

> Ты сначала попробуй в виртуалке. Думаю, ты быстро переменишь мнение.

Из трех ноутов одного на опыты не жалко. А какие _еще_ (кроме ввода в терминалах) истории неуспеха имеются?

shimon ★★★★★
()

آНа машине тоже можно разбиться и что? Перестать на ней ездить?

Ab-1
()
Ответ на: комментарий от shimon

А какие _еще_ (кроме ввода в терминалах) истории неуспеха имеются?

Все сказанное ниже относится к OpenSolaris:

  • Не выбирай русский язык по умолчанию при установке — не залогинишься потом в систему.
  • Идиотская система управления пакетами. Слопать 200+ мег RSS при апдейте одного пакета для нее раз плюнуть.
  • DE из коробки только GNOME и памяти при этом кушается в районе гига (запускаешь фаерфокс, а на thunderbird — welcome to swap)
  • Крайне враждебное окружение, к которому надо привыкать.
  • В стабильном релизе (osol-0906) крайне древний софт. С нестабильным релизом будут проблемы (у меня, к примеру, проблемы с драйвером для интеловской видеокарточки, отрисовывается по-весовски долго)
  • Крайне мало софта в официальных репозиториях.
  • Есть официальный «non-free», но для доступа к нему надо регистрироваться на сайте и получать ключ. Таким путем ставится, например, флешевый плагин.

Практически ко всему легко привыкнуть кроме враждебного окружения. Ощущения примерно как на windows -> linux в первый раз.

linuxfan
()
Ответ на: комментарий от iZEN

>> Ну если я правильно понимаю, то это означало бы, что ZFS перелицензирована под чтото гнутое, а значит у фряхи вырывают последний несгнивший зубик. Или не?

Код ZFSv14 под CDDL уже в ядре FreeBSD. Перелицензирование обратной силы не имеет — все выпущенные продукты невозможно перелицензировать, можно поставить новое клеймо только на новый продукт. Так-то.

Рехнуться, с какого-якого Вы это взяли? С каких пор правообладатель не может сделать двойное (тройное, да хоть n-ное) лицензирование в любой момент времени? Что может [новому] правообладателю на код и вероятные патенты изначально CDDL-ный код на модуль ZFS лицензировать под GPL, сохранив его же и под изначальной лицензией?

Я, кажется, понимаю. Любовь к BSL-like лицензиям связана с неумением/нежеланием разбираться с юридической стороной.

Ingwar ★★★★★
()
Ответ на: комментарий от Ingwar

С каких пор правообладатель не может сделать двойное (тройное, да хоть n-ное) лицензирование в любой момент времени?

В любой момент — может. Вот с этого момента и пойдёт отсчёт новго времени для «обновлённого» продукта. Старые калоши останутся резиновыми.

Что может [новому] правообладателю на код и вероятные патенты изначально CDDL-ный код на модуль ZFS лицензировать под GPL, сохранив его же и под изначальной лицензией?

Только у себя в исходниках, расширь свой кругозор.

Код под CDDL позволяет редактировать себя кем угодно, правки выкладываются под той же лицензией, но линковаться с чем угодно под другими лицензиями.

Код под GPL позволяет редактировать себя кем угодно, правки выкладываются под той же лицензией, но линковаться СТАТИЧЕСКИ с чем угодно под другими лицензиями НЕ может.

Код под BSDL позволяет редактировать себя кем угодно, правки необязательно выкладывать под той же лицензией, но линковаться с чем угодно под какими угодно лицензиями с перечислением имён авторов исходного кода и приложением текста лицензии. Так что будь код хоть трижды GPL, свою заразность он теряет в BSDL-презервативе обёртке, когда загружается и используется ДИНАМИЧЕСКИ (в виде модуля, например). В FreeBSD куча кода под GPL, динамически линкуемая подгружаемая во время работы ядра (linux.ko, например).

Если будут какие-либо препятствия в виду патентных ограничений, которые, возможно, не заставят себя долго ждать из-за двуличной природы корпорастов, то будет разруливание ситуации как с алгоритмом IDEA — перекладывание всей ответственности за нарушение американского (не не европейского и не российского) законодательства на пользователя. :))

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

>В любой момент — может. Вот с этого момента и пойдёт отсчёт новго времени для «обновлённого» продукта. Старые калоши останутся резиновыми.

так, давайте отделим мух от котлет. если вася напишет код под CDDL, потом доростит свой код до версии 0.3.0, то он совершенно справедливо может перелицензировать любую из версий в любую другую лицензию. «калоши» можно не обновлять. вася может объявить все предыдущие версии до версии 0.2.99 _также_ лицензируемыми под GPL, к примеру. конечно, лицензия CDDL на эти версии никуда не денется, но двойное лицензирование может начинаться с любой версии и в любой момент. он не может отозвать все уже заключенные соглашения (читай, если ты согласился следовать CDDL, то вася не может у тебя отобрать право в дальнейшем использовать продукт указанных версий под CDDL)

Полное перелицензирование, действительно, требует «смены калош», то есть требует от производителя объявления новой ветки, и в этом случае действительно «старые калоши» вася оставит под CDDL, а новые — под GPL. При этом, если кто-то захочет развивать код под старой лицензией, обязан будет форкнуть основной продукт старой версии.

Только у себя в исходниках, расширь свой кругозор.

ключевое слово «правообладателю», а не лицензиату.

Оракл, поглотив Сан инк, поглотил и все его наработки, патенты и авторские права, принадлежавшие ранее санкам. Соответственно, и права на имущественные объекты авторского права, касающиеся ZFS в том числе. Соответсвенно, Оракл _волен_ поступать с лицензиями, как ему вздумается: захочет сделает ZFS под _второй_ лицензией GPL, захочет — опубликует MySQL под MIT (имущественные права на этот продукт сосредоточены в одних руках, коммитеры обязаны были согласиться с этим, когда их патч принимался еще в MySQL AG).

В то же время, даже «только у себя в исходниках» никто из лицензиатов не может поменять лицензию, даже если скроет от глаз свой код. комбинировать продукты под разными лицензиями может, но не может потом этот код распространять ни в текстовом, ни в бинарном виде.

Код под GPL позволяет редактировать себя кем угодно, правки выкладываются под той же лицензией, но линковаться СТАТИЧЕСКИ с чем угодно под другими лицензиями НЕ может.

Категорическое нет. Вы немного не понимаете смысла GPL. Вы считаете, что Столлман придумал страшную лицензию, которая несовместима ни с чем. Но на самом деле при определенных условиях GPL прекрасным образом линкуется с продуктами других лицензий. Условие, надо сказать, только одно — лицензия исходного продукта не может накладывать больше ограничений на производный продукт, чем на производный продукт накладывает сама GPL. То есть, если MIT, new-BSD и LGPL не накладывают больше ограничений чем GPL, то хоть облинкуйся, главное соблюдай условия обеих лицензий. Правда, производный продукт будет распространяться только под GPL — все ее ограничения и так являются надмножеством совместимых с ней лицензий.

В FreeBSD куча кода под GPL, динамически линкуемая подгружаемая во время работы ядра (linux.ko, например).

Тут Вы совершенно правы, программа BSD может динамически линковать объекты любых других лицензий, фактически являясь пускалкой для объекта, а GPL — не позволяет. Но на этот случай для GPL есть свой презерватив, который может позволить связать два модуля с несовместимыми лицензиями (GPL и иная лицензия) . Это LGPL. Подгружайте обе библиотеки динамически в обертку LGPL — и Вы получите то же самое, что и с BSDL. Но, что и говорить, способ не какой универсальный, это да.

По последнему абзацу я полностью с Вами согласен.

Но вернемся к Ораклу и ZFS. Дай бог, чтобы Ораклу внезапно понадобилась ZFS в ядре своих Linux-платформ, которые они продают. Ведь тогда им ничего не останется, как дополнительно лицензировать ZFS под GPL (а права лицензиара у Оракла имеются в полном объеме), и тогда Linux прирастет еще одной хорошей файловой системой. При этом из Оракла идут всевозможные заверения, что работы по btrfs не останавливаются. Так что при хороших раскладах мы получим две новые хорошие файловые системы, а при плохих — только одну ;)

Ingwar ★★★★★
()
Ответ на: комментарий от linuxfan

> Не выбирай русский язык по умолчанию при установке — не залогинишься потом в систему.

Выбрал украинский и залогинился. ~:o{)

Идиотская система управления пакетами. Слопать 200+ мег RSS при апдейте одного пакета для нее раз плюнуть.


Обновляю до нестабильного, полет нормальный.

И да, у меня в гнометерминале все работает, фантастишь!

shimon ★★★★★
()
Ответ на: комментарий от shimon

>И да, у меня в гнометерминале все работает, фантастишь!

У меня, собственно, тоже работало, пока я не снес кривой пакет интернационализации и не стал задавать настройки клавиатуры через setxkbmap.

Обновляю до нестабильного, полет нормальный.

Ну посмотрим, чем это закончится.

linuxfan
()
Ответ на: комментарий от linux4ever

>Или 0, если оракл забъет на линугз.

не забьет. линукс сейчас слишком ожидаемая клиентом вещь. слишком sexy для энтерпрайзного потребителя, чтобы от него отказываться.

Ingwar ★★★★★
()
Ответ на: комментарий от iZEN

>Из-за выделения непрерывного пространства в последнем блоке с данными образуется малозаметное неиспользуемое пространство вследствие целого числа блоков, требуемого для хранения данных файлов. Например, на разделе размером 100ГБ и размере блока ФС 4кбайта образуются незаполненные блоки размером 0...3,99кбайта. Сколько файлов с размером не кратным размеру блока ФС — столько и незаполненных блоков. Теперь посчитай, сколько полезного пространства расходуется у тебя на Ext2/3 на такие вот не доконца заполненные блоки.

Не решает. при 72000 файлов, например (у меня на хомяке) в среднем гуляет 72000*4*0.5=140000КБ. Приемлемая цена за уменьшение фрагментации и скорость.

Когда на диске с Ext2/3 пишутся и стираются файлы, непрерывных отрезков с блоками становится всё меньше, и целые блоки для хранения данных новых файлов начинают выделяться в произвольных местах диска — на месте ранее стёртых файлов. Естественная фрагментация файлов растёт из-за малой «гранулярности» пространства носителя.

К UFS2 применимо в той же степени. Гранулярность в данном сучае роли не играет (ведь ufs2 приходится уменьшать гранулярность, когда это нужно, иначе та же потеря места).

В UFS2 используется адресация фрагментов блоков, так что хранение данных осуществляется более экономично: во-первых, непрерывное пространство выделяется не только из целых незанятых блоков, но и из последовательности фрагментов не доконца занятых блоков; во-вторых, для больших файлов используются блоки переменного/увеличенного размера (максимум в 8 раз больше стандартного 16кбайт) — это ещё одна степень свободы политики размещения и уменьшения фрагментации.

1) На фрагментацию это никак не влияет. Разве что немного меньшая нагрузка на процессор (из-за большего размера блока для больших файлов), что полностью съедается тем фактом, что приходится иногда выковыривать «части» блоков.

dikiy ★★☆☆☆
()
Ответ на: комментарий от iZEN

> во-вторых, для больших файлов используются блоки переменного/увеличенного размера (максимум в 8 раз больше стандартного 16кбайт)

А можно ссылочку на место в коде UFS2 где это делается? А то есть подозрение, что этот код еще не написан...

ZFSych
()
Ответ на: комментарий от linuxfan

>Практически ко всему легко привыкнуть кроме враждебного окружения.

gnu-окружение туда первым делом ставится обычно

madcore ★★★★★
()
Ответ на: комментарий от madcore

>> Практически ко всему легко привыкнуть кроме враждебного окружения.

gnu-окружение туда первым делом ставится обычно

Так там и так вроде GNU-утилиты первыми в путях. Возможно, что не все, к чему успели привыкнуть, имеется после начальной установки, но в чем проблема доставить отсутствующее из репозитария?

ZFSych
()
Ответ на: комментарий от linuxfan

>netstat, ifconfig и прочая системная начинка там совсем не гнутая.

Да даже ping неправославный. Но вопрос с гну-окружением легко решаем.

madcore ★★★★★
()
Ответ на: комментарий от ZFSych

> А можно ссылочку на место в коде UFS2 где это делается? А то есть подозрение, что этот код еще не написан...

Я не разбираюсь в плохо откомментированном исходном коде, но возможно процедуры аллокации новых блоков описаны в файле /usr/src/sys/ufs/ffs/ffs_balloc.c (модификация: v 1.55.2.1 2009/08/03 08:13:06).
Возможно код выделения блоков увеличенного размера (скорее — любого возможного для ФС размера) написан именно там. Сказать наверняка не могу — я не C-программист.

iZEN ★★★★★
()
Ответ на: комментарий от madcore

>> netstat, ifconfig и прочая системная начинка там совсем не гнутая.

Дык это системные вещи, они поди в любой системе отличаются. Может быть вы хотели сказать «не линуксовая»? Дык это и не Линукс, это OpenSolaris.

Да даже ping неправославный. Но вопрос с гну-окружением легко решаем.

Сомневаюсь, что можно легко найти гнутые аналоги dladm и flowadm, например.

Но со всякими утилитами обработки текстов, простыми командами, инструментами разработчика особых проблем быть не должно.

ZFSych
()
Ответ на: комментарий от Ingwar

> так, давайте отделим мух от котлет. если вася напишет код под CDDL, потом доростит свой код до версии 0.3.0, то он совершенно справедливо может перелицензировать любую из версий в любую другую лицензию. «калоши» можно не обновлять. вася может объявить все предыдущие версии до версии 0.2.99 _также_ лицензируемыми под GPL, к примеру.

Ошибаетесь. Лицензионное соглашение обратной силы не имеет.

Первая версия продукта, вышедшая под одной лицензией, не может изменить лицензионный договор кроме как через выпуск следующей модификации/версии/.


Полное перелицензирование, действительно, требует «смены калош», то есть требует от производителя объявления новой ветки, и в этом случае действительно «старые калоши» вася оставит под CDDL, а новые — под GPL.


Именно.

При этом, если кто-то захочет развивать код под старой лицензией, обязан будет форкнуть основной продукт старой версии.


Не обязан. Будет форк на основе патчей. К тоу же возможен вариант нераспространения, для внутреннего использования — сам способ, или ноу-хау, по «адаптации» продукта будет иметь отличные от самого продукта авторские и имущественные права.

В то же время, даже «только у себя в исходниках» никто из лицензиатов не может поменять лицензию, даже если скроет от глаз свой код.


Это просто не нужно. Если производный продукт не распространяется, то и изменённые CDDL- и GPL-защищённые исходники выкладывать не нужно.

Правда, производный продукт будет распространяться только под GPL — все ее ограничения и так являются надмножеством совместимых с ней лицензий.


Однако лицензия FreeBSD (файл /COPYRIGHT) — набор вариаций BSDL и только для некоторых файлов — GPL.

Но вернемся к Ораклу и ZFS. Дай бог, чтобы Ораклу внезапно понадобилась ZFS в ядре своих Linux-платформ, которые они продают.


А такой сценарий: оставляют весь код ZFS под CDDL; для ядра пишут загружаемый модуль под LGPL. Возможен?

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

> Я не разбираюсь в плохо откомментированном исходном коде, но возможно процедуры аллокации новых блоков описаны в файле /usr/src/sys/ufs/ffs/ffs_balloc.c (модификация: v 1.55.2.1 2009/08/03 08:13:06). Возможно код выделения блоков увеличенного размера (скорее — любого возможного для ФС размера) написан именно там. Сказать наверняка не могу — я не C-программист.

Ладно, а как тогда прокомментировать вот это:

http://sixshooter.v6.thrupoint.net/jeroen/faq.html#UFS2-PERF

1.10. Does UFS2 offer any performance improvement over UFS1?

UFS2 has the potential to be faster for really large files by using jumbo blocks, but the code to do that has yet to be written. Additionally, because inodes are lazily initialized in UFS2, newfs(8) runs much faster. Other than that, UFS2 performance should not significantly differ from UFS1.

ZFSych
()
Ответ на: комментарий от dikiy

> при 72000 файлов, например (у меня на хомяке) в среднем гуляет 72000*4*0.5=140000КБ. Приемлемая цена за уменьшение фрагментации и скорость.

Не критерий.
Фрагментация на Ext2/3 растёт сильнее при интенсивных операциях записи/удаления, чем на UFS2 за счёт меньшего количества свободных целых блоков в группах блоков и, как следствие, — уменьшение участков с последовательностями целых блоков. Итог: части файлов раскидываются по диску на больших расстояниях логической адресации (==части файлов будут находится в разных группах блоков).

К UFS2 применимо в той же степени. Гранулярность в данном сучае роли не играет (ведь ufs2 приходится уменьшать гранулярность, когда это нужно, иначе та же потеря места).


Иначе не бывает. Блок стандартный 16кбайт делится на фрагменты по 2кбайта. Стандартный блок может быть автоматически увеличен в 16 раз (а не в 8 — в прошлый раз ошибся), то есть до 256кбайта для больших файлов. Фрагменты не доконца занятых блоков будут использованы для записи новых файлов, сохраняя непрерывность/последовательность вновь занимаемых блоков и фрагментов, укладывающихся внутри групп цилиндров или же в смежных группах цилиндров, по-любому.

Разве что немного меньшая нагрузка на процессор (из-за большего размера блока для больших файлов), что полностью съедается тем фактом, что приходится иногда выковыривать «части» блоков.


Нет. Просто есть загрузка в память блоков данных, фрагменты которых реально не нужны — это части не нужных файлов в общих блоках.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

> Стандартный блок может быть автоматически увеличен в 16 раз (а не в 8 — в прошлый раз ошибся), то есть до 256кбайта для больших файлов.

Откуда такие сведения?

Вот эта проверка в самом начале ffs_balloc_ufs2() намекает что это, мягко говоря, не так:

   if (size > fs->fs_bsize)       panic(«ffs_balloc_ufs2: blk too big»);

То есть если качестве размера передать значение, большее, чем размер блока, записанный в суперблоке, то произойдет паника.

Ы??

ZFSych
()
Ответ на: комментарий от ZFSych

Вот эта проверка в самом начале ffs_balloc_ufs2() намекает что это, мягко говоря, не так:

if (size > fs->fs_bsize) panic(«ffs_balloc_ufs2: blk too big»);

Ага:

ip = VTOI(vp);
	dp = ip->i_din2;
	fs = ip->i_fs;
	ump = ip->i_ump;
	lbn = lblkno(fs, startoffset);
	size = blkoff(fs, startoffset) + size;
	if (size > fs->fs_bsize)
		panic("ffs_balloc_ufs2: blk too big");
— точь-в-точь как у UFS1.

Код для выделения блоков UFS2 писался методом copy-paste от процедуры ffs_balloc_ufs1(). Новый код представляет собой лишь алгоритмы работы с блоками внешних (расширенных) атрибутов.

То есть если качестве размера передать значение, большее, чем размер блока, записанный в суперблоке, то произойдет паника.

Размер блока UFS2 хранится в самом inode, в поле — см. файл src/sys/ufs/ufs/dinode.h,v 1.18.2.1 2009/08/03 08:13:06:

u_int32_t	di_blksize;	/*  12: Inode blocksize. */.

В суперблоке UFS2 хранится размер базовых блоков, размер фрагментов блоков и количество фрагментов в блоке — см. файл src/sys/ufs/ffs/fs.h,v 1.50.2.1 2009/08/03 08:13:06:

/*
 * Super block for an FFS filesystem.
 */
struct fs {
...
	int32_t	 fs_bsize;		/* size of basic blocks in fs */
	int32_t	 fs_fsize;		/* size of frag blocks in fs */
	int32_t	 fs_frag;		/* number of frags in a block in fs */
...
Копии суперблока хранятся в каждой группе цилиндров. Так что...

Может быть существует код, который меняет размер базового блока ФС в суперблоке группы цилиндров и тогда вполне возможно использование блоков большего размера внутри группы? Хотя вряд ли — файлы могут пересекать границы групп цилиндров, тогда размещение будет слишком расточительно (файлы размещаются в блоках фиксированного размера).

Похоже, все врут: и Wikipedia, и обозреватели, расписывающие дополнительное свойство UFS2 как «переменный размер блока». Пока что можно увидеть задел, но код аллокации блоков большого (переменного) размера, к сожалению, ещё не написан. ;)

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

Насколько я успел рассмотреть,

u_int32_t di_blksize; /* 12: Inode blocksize. */.

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

Однако существует код, который поддерживает информацию о наличии нерпрерывных кластеров блоков (насколько я понимаю, до 16 подряд), и эта информация используется для расположения блоков базового размера один за другим, по мере возможности. То есть при наличии кластеров свободных блоков, ФС из будет использовать. Однако, это никак не уменьшает количество метаданных файла - количество отдельных блоков остается одним и тем же; а вот количество метаданных группы цилиндров увеличивается, так как надо хранить и поддерживать в актуальном состоянии суммарную информацию о наличии кластеров, и карту их расположения (вроде так).

ZFSych
()
Ответ на: комментарий от iZEN

>Ошибаетесь. Лицензионное соглашение обратной силы не имеет.

где я говорил, что лицензионное соглашение имеет обратную силу?

публичное соглашение имеет юридическую силу в отношении только двух лиц — лицензиара и лицензиата(если лицензиар не связан иными ограничениями).

и то что я(держатель всех имущественных прав на продукт) с васей заключил лицензионное соглашение «договор первого вида», то с петей заключить «договор второго вида» мне никто не помешает. новый договор с петей никак не отменяет договор с васей.

Первая версия продукта, вышедшая под одной лицензией, не может изменить лицензионный договор кроме как через выпуск следующей модификации/версии/.

как рождается такой параноидальный бред? вот объясните, на основе каких таких наблюдений вы делаете такой вывод? кто мне запретит открыть исходники продукта версии 1.0 под любой свободной лицензией, если изначально распространялся под только под EULA? Кто запретил Беркли в один день сменить для всех своих продуктов изменить old-bsd на new-bsd?

Ingwar ★★★★★
()
Ответ на: комментарий от Ingwar

> кто мне запретит открыть исходники продукта версии 1.0 под любой свободной лицензией, если изначально распространялся под только под EULA?

Никто. Смена лицензии в сторону _урезания_ прав сторон не допускается. При смене EULA -> public права расширяются, а не урезаются.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

>> при 72000 файлов, например (у меня на хомяке) в среднем гуляет 72000*4*0.5=140000КБ. Приемлемая цена за уменьшение фрагментации и скорость.

Не критерий.

Фрагментация на Ext2/3 растёт сильнее при интенсивных операциях записи/удаления, чем на UFS2 за счёт меньшего количества свободных целых блоков в группах блоков и, как следствие, — уменьшение участков с последовательностями целых блоков. Итог: части файлов раскидываются по диску на больших расстояниях логической адресации (==части файлов будут находится в разных группах блоков).

Ты сам понял, что сказал?

К UFS2 применимо в той же степени. Гранулярность в данном сучае роли не играет (ведь ufs2 приходится уменьшать гранулярность, когда это нужно, иначе та же потеря места).

Иначе не бывает. Блок стандартный 16кбайт делится на фрагменты по 2кбайта. Стандартный блок может быть автоматически увеличен в 16 раз (а не в 8 — в прошлый раз ошибся), то есть до 256кбайта для больших файлов. Фрагменты не доконца занятых блоков будут использованы для записи новых файлов, сохраняя непрерывность/последовательность вновь занимаемых блоков и фрагментов, укладывающихся внутри групп цилиндров или же в смежных группах цилиндров, по-любому.

Это на фрагментацию не влияет, 3й раз говорю. Просто на ФС места чуть больше оказывается.

На ext3 просто между файлами будут небольшие «дырки» в виде не до конца заполненных блоков, ну и что? Все равно в эти дырки ничего не записать больше.

dikiy ★★☆☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.