форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
Сообщение от opennews (??) on 23-Июн-11, 12:28
Эрик Сандин (Eric Sandeen) из компании Red Hat проанализировал (http://sandeen.net/wordpress/?p=532) интенсивность развития файловых систем Ext4 (https://ext4.wiki.kernel.org/), Btrfs (https://btrfs.wiki.kernel.org/index.php/Main_Page) и XFS (http://www.xfs.org/), изучив число связанных с данными ФС строк кода в различных версиях Linux-ядра. Результаты получились довольно интересными: на протяжении нескольких лет, размер кода (комментарии не учитывались), связанного с XFS уменьшается, что свидетельствует (http://xfs.org/index.php/XFS_Status_Updates) о проводимых оптимизациях и избавлении от лишнего груза. XFS постепенно избавляется от изначально присущей (http://lkml.org/lkml/1999/5/24/65) данной ФС усложненности и запутанности кодовой базы. В отличие от XFS, файловые системы Ext4 и Btrfs идут по пути постоянного усложнения. Наибольший рост кодовой базы Ext4 наблюдался во время выпуска ядер 2.6.24-2.6.27, в дальнейшем размер кодовой базы почти линейно постоянно увеличивается (за вр... URL: http://www.phoronix.com/scan.php?page=news_item&px=OTU4OA Новость: http://www.opennet.me/opennews/art.shtml?num=30970
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+2 +/–
Сообщение от Аноним (??) on 23-Июн-11, 12:28
> В отличие от XFS, файловые системы Ext4 и Btrfs идут по пути постоянного усложнения. Проблема только в том что у XFS строк уже больше, а у btrfs фичность как-то поболее будет :))) > комментарии составляют примерно 39% от всего размера кода. Суровые парни. Этак скоро маны будут прямо в сорцы копипастить :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+10 +/–
	Сообщение от klalafuda on 23-Июн-11, 12:41
	> Суровые парни. Этак скоро маны будут прямо в сорцы копипастить :) Ну вообще то генерация документации в т.ч. манов на основании соотв. образом представленных комментариев - это мягко говоря давно не новость. Doxygen & K в руки как пример. Скорее, вопрос в первую очередь в алаберности или же безалаберности кодеров что все это ваяют. Станут ли они писать вменяемую документацию к своим творениям или нет. Конечная же форма изъявления мыслей не особо принципиальна.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	14. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–1 +/–
	Сообщение от Аноним (??) on 23-Июн-11, 14:10
	> Ну вообще то генерация документации в т.ч. манов на основании соотв. образом > представленных комментариев - это мягко говоря давно не новость. Правда вот такие мануалы обычно стойко навевают воспоминания о анекдоте "моя скорость печати - 1200 знаков в минуту! Правда такая фигня получается..."
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	46. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от ананим on 23-Июн-11, 17:01
	неа. а вот такие коментари уж точно навевают мысли о быдлокодере. признайся сразу что ты не кодер вообще. так будет всем лучше. :D зыж > Ну вообще то генерация документации в т.ч. манов на основании соотв. образом представленных комментариев я бы даже сказал что это суровая необходимость. И если бы ей следовали все, то как проще бы жилось чесслово.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	50. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–1 +/–
	Сообщение от fr0ster (ok) on 23-Июн-11, 17:12
	> я бы даже сказал что это суровая необходимость. > И если бы ей следовали все, то как проще бы жилось чесслово. А тут надо помнить, что административные проблемы не решаются техническими средствами. Надо до начала проекта решить >>все<< вопросы, не только какой язык программирования, какой фреймворк, какую архитектуру использовать, но и как комментировать код, как именовать объекты, как писать документацию, как проверять код на соответствие принятым на проекте стандартам. В общем скажете это азы, будете правы, скажете КО, опять будете правы, но 90% проблем это именно из за игнорирования мелочей на проектах даже не самых мелких. И это не только в СПО, в СПО еще ничего, а вот код писанный в коммерческих конторах... ЗЫ Да я знаю, что когда говорят код нужен "на вчера" только святой удержится от написания наколеночного кода, лишь бы работало здесь и сейчас.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	54. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–1 +/–
	Сообщение от ананим on 23-Июн-11, 17:19
	>А тут надо помнить, что административные проблемы не решаются техническими средствами. Э-э-э-э... О чём Вы? Комментарии к коду - не административная проблема, а техническая. когда это начинают понимать (порой поздно), то прекрасно решают её административными средствами. Вот только какие же административные средства в джаст4фан? :D >ЗЫ Да я знаю, что когда говорят код нужен "на вчера" только святой удержится от написания наколеночного кода, лишь бы работало здесь и сейчас. привычка - вторая натура. даже быдло-код производится с теми же сроками и с тем же количеством комментов. ЭТО не вопрос. :D
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	58. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от ананим on 23-Июн-11, 17:26
	зыж >>ЗЫ Да я знаю, что когда говорят код нужен "на вчера" только святой удержится от написания наколеночного кода, лишь бы работало здесь и сейчас. >привычка - вторая натура. >даже быдло-код производится с теми же сроками и с тем же количеством комментов. айзен жабадок снизу уже привёл в качестве "доказательства". А я даже добавлю - все современно-модные ИДЕ генерируют шаблоны классов/процедур/фу... вместе с этим "жабадоком". при этом порой любезно сворачивая эти "доки" в одну строчку. чтоб не мешали так сказать быдлокодить. :D но если серьёзно, то однажды появившаяся привычка оставлять комментарии (при чём не для дяди, а для себя любимого. Ибо через день уже "забываешь" чё там накодил Вчера в пылу "озарения") очень сильно помогает в дальнейшем.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	62. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от fr0ster (ok) on 23-Июн-11, 17:32
	> но если серьёзно, то однажды появившаяся привычка оставлять комментарии (при чём не > для дяди, а для себя любимого. Ибо через день уже "забываешь" > чё там накодил Вчера в пылу "озарения") очень сильно помогает в > дальнейшем. Я с этим столкнулся не на жабе а на абапе, но вот привычка комментить чуть ли не каждую строку и правда сильно помогает. Иногда даже прикрыть хвост. :)
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	102. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–2 +/–
	Сообщение от anonymous (??) on 23-Июн-11, 22:21
	если каментить надо каждый чих — то это быдлокод: нормальный код отлично читается без каментов. надо писать каменты только там, где используются неочевидные хаки; а это очень мизерное количество кода. если хаки раскиданы везде… ну, лучше всего пейсателей расстрелять, а потом уволить.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	59. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от fr0ster (ok) on 23-Июн-11, 17:26
	>>А тут надо помнить, что административные проблемы не решаются техническими средствами. > Э-э-э-э... О чём Вы? > Комментарии к коду - не административная проблема, а техническая. > когда это начинают понимать (порой поздно), то прекрасно решают её административными средствами. Техническая это использовать Доксиген или еще чтото для документирования, а требование комментить код под угрозой непринятия кода это административное средство. > Вот только какие же административные средства в джаст4фан? :D В джаст4фан административные средства те же самые, только чел применяет их сам к себе. Чувство гордости за труд, который не стыдно показать другим. Все то же, одним словом. >>ЗЫ Да я знаю, что когда говорят код нужен "на вчера" только святой удержится от написания наколеночного кода, лишь бы работало здесь и сейчас. > привычка - вторая натура. Привычка тут ни причем. > даже быдло-код производится с теми же сроками и с тем же количеством > комментов. Кто комментирует код, когда уверен, что он на один раз, выполнить и выбросить? > ЭТО не вопрос. :D Именно вопрос, когда постановщик говорит, давай сделаем эту процедуру для использования в таких строго ограниченных условиях, а позже оказывается, что условия несколько расширились, и обстоятельства изменились.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	65. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от ананим on 23-Июн-11, 17:40
	>Техническая это использовать Доксиген или еще чтото для документирования, а требование комментить код под угрозой непринятия кода это административное средство. ну дык и я о чём? Важно не путать проблемы со средствами. хорошо документированный код - это техническая проблема. Хотя её "техничность" проявляется только со временем. Решается как правило административно. Был даже опытЪ в одной конторе - требование на 4-5 строчек кода должна быть 1 строчка комментария. Во народ изгалялся! :D
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	74. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от fr0ster (ok) on 23-Июн-11, 18:01
	>>Техническая это использовать Доксиген или еще чтото для документирования, а требование комментить код под угрозой непринятия кода это административное средство. > ну дык и я о чём? > Важно не путать проблемы со средствами. > хорошо документированный код - это техническая проблема. Хотя её "техничность" проявляется > только со временем. Хорошо документированный код это вообще не проблема. Плохое документирование техническая проблема, только если ваши технические средства (ИДЕ, редактор и тп) не дают вам комментить ясно и понятно, но это абсурд, нет таких редакторов, которые бы не давали вам писать коммент больше одной строки. Так что хреновое комментирование и документирование это административная проблема. > Решается как правило административно. Естественно, проблема административная и решается административно. Техническая проблема решаемая административно это бросание персонала "грудью на амбразуру" под угрозой премирования :) > Был даже опытЪ в одной конторе - требование на 4-5 строчек кода > должна быть 1 строчка комментария. Во народ изгалялся! :D Ну дык должен же быть какой то контроль, прием кода наконец. Иначе эти все методы будут чистой фикцией.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	81. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от ананим on 23-Июн-11, 18:32
	>Так что хреновое комментирование и документирование это административная проблема. фиг там. Административная она до тех пор, пока кода мало, а тот кто его написал ещё не уволился. И кто сказал что технические проблемы не решаются административно? Примеры - новый сервер, новое ПО, новые сотрудники наконец - всё это позволяет решить ряд сугубо технических проблем. >Естественно, проблема административная и решается административно. ещё раз - документирование кода превращается легко в техническую проблему с течением времени. И не всегда её кстати можно решить даже технически, не говоря уже об административном. интеграторы точно знают о чём я сейчас говорю. Легаси-код, сырцы на который давно утеряны и полное отсутствие документации очень часто приводят к тому, что приходится всё "сломать" и сделать по другому вместо поэтапного внедрения и с соответствующими расходами. При этом код точно был. Когда-то и где-то, но никто не знает где. :D
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	99. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–1 +/–
	Сообщение от fr0ster (ok) on 23-Июн-11, 21:43
	>>Так что хреновое комментирование и документирование это административная проблема. > фиг там. > Административная она до тех пор, пока кода мало, а тот кто его > написал ещё не уволился. Это всегда административная проблема. Если руководитель допустил завязанность проекта на одного человека и он стал невзаимозаменяемым, это сугубо административная проблема. > И кто сказал что технические проблемы не решаются административно? > Примеры - новый сервер, новое ПО, новые сотрудники наконец - всё это > позволяет решить ряд сугубо технических проблем. Новый сервер это техническое решение, административное это реорганизация, найм сотрудников. >>Естественно, проблема административная и решается административно. > ещё раз - документирование кода превращается легко в техническую проблему с течением > времени. > И не всегда её кстати можно решить даже технически, не говоря уже > об административном. Технически можно временно заткнуть дыру, административно можно ликвидировать причину возникновения проблемы. > интеграторы точно знают о чём я сейчас говорю. Легаси-код, сырцы на который > давно утеряны и полное отсутствие документации очень часто приводят к тому, > что приходится всё "сломать" и сделать по другому вместо поэтапного внедрения > и с соответствующими расходами. Каковы причины появления легаси-кода и утери сырцов? Исключительно административные. > При этом код точно был. Когда-то и где-то, но никто не знает > где. :D Ага, не подумали как все организовать заранее, то приходится дыры затыкать хоть как то.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	134. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от ананим on 24-Июн-11, 03:33
	>Это всегда административная проблема. Если руководитель допустил завязанность проекта на одного человека и он стал невзаимозаменяемым, это сугубо административная проблема. эх, молодо-зелено... Через дцать лет любой проект завязан на "одного" человека. Да и руководителей уже дцать на пенсию проводили. >Каковы причины появления легаси-кода и утери сырцов? Исключительно административные. а какая разница? Факт тот, что теперь это уже техническая проблема. >Ага, не подумали как все организовать заранее, то приходится дыры затыкать хоть как то. Ну всё, закрываем контору и уходим на пенсию. :D А поскольку контора градообразующая, то всем городом. Ну а чё, сами виноваты. Не предусмотрели ни винду, ни линух, как написали на кларионе/бтриве/парадоксе, так и работают. блин гейс, сцуко не сказал, что эти перспективные технологии загнутся. :D
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	157. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от ананим on 24-Июн-11, 11:02
	какие в попу сейчас госконторы? тут вон Путин возмущался что в приморье таможню уже в аренду берут, а вы говорите... Госконторы - это не пенсионный фонд случаем? А там уже счёты на калькуляторы заменили? О-о-о! :D Нет. просто крупные предприятия. причем поголовно. от мясокомбинатов, до станкостроительных заводов и банков (да-да!!! банков) отсюда вывод, который вы и сами наметили - если старшие говорят что мы живём в опе, то вы только можете догадываться в какой по объёму. При этом все мелкие конторы сейчас пишут под себя точно так же. И если они через дцать лет и станут крупными, то тоже будут в том же анусе что и все.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 23-Июн-11, 17:22
	> признайся сразу что ты не кодер вообще. так будет всем лучше. :D Признаюсь в том что автоматически сгенеренная документация - как правило такой же бред как автоматически сгенеренные стихи. То-есть, читать нормальную, писанную человеком который шарил в вопросе - сильно быстрее, доходчивее и приятнее. А автогенерация - это работа по принципу "на отвали". Конечно, если никакой документации вообще нет - и такое сожрать можно. Подметки тоже жратва, если ничего другого не осталось. > я бы даже сказал что это суровая необходимость. Я бы даже сказал что нормальная документация - вкуснее таких портянок. > И если бы ей следовали все, то как проще бы жилось чесслово. А уж если бы люди писали бы нормальную документацию и руками, а не гребаными автогенераторами - и подавно.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	61. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 23-Июн-11, 17:31
	http://wiki.lustre.org/lid/subsystem-map/subsystem-map.html вот документация которая генерится из исходников. Автоматически. Считаете это "на отвали" ?
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	75. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 23-Июн-11, 18:05
	> Считаете это "на отвали" ? Да как сказать? Фифти-фифти. Врубиться по этой доке в принципе можно. Но читать нормально написанные доки, без странных заглушек (половина которых видимо принадлежит перу Капитана Очевидности) - приятнее и результативнее.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	77. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от fr0ster (ok) on 23-Июн-11, 18:11
	> Да как сказать? Фифти-фифти. Врубиться по этой доке в принципе можно. Но > читать нормально написанные доки, без странных заглушек (половина которых видимо принадлежит > перу Капитана Очевидности) - приятнее и результативнее. Вообще говоря дока автоматом сгенерированная из нормально написанных комментариев в коде ничем не хуже нормально написанной документации. К сожалению для нормальной написанной документации нужен талант больший, чем для нормального комментария к коду.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	126. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 24-Июн-11, 01:21
	> Вообще говоря дока автоматом сгенерированная из нормально написанных комментариев в коде > ничем не хуже нормально написанной документации. Честно говоря, сырцы и коменты в них я могу почитать и без тупых автогенераторов. А вот читать тот бред который выдают на гора автоматические бредогенераторы меня почему-то не очень прельщает. Нет, что-то они безусловно выдают. Иногда это что-то даже слегка полезно. Проблема только в том что полноценной документацией это ни разу не является.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	128. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??) on 24-Июн-11, 01:28
	> Проблема только в том что полноценной документацией это ни разу не является. авторы Qt удивлены.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	165. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 24-Июн-11, 12:19
	> авторы Qt удивлены. Они не умеют использовать grep? :)
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	98. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+2 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 23-Июн-11, 21:33
	> http://wiki.lustre.org/lid/subsystem-map/subsystem-map.html > вот документация которая генерится из исходников. > Автоматически. > Считаете это "на отвали" ? Автоматически генерируемая документация полезна при использовании библиотек, так как при грамотной реализации позволяет быстро находить информацию о том или ином вызове. В собственном конечном проекте она, как правило, бесполезна, так как не добавляет никакой новой информации к редактироемому коду. Документация должна дополнять код, давать ту информацию, которую явным образом из кода не видно. Документация, которая дублирует то, что и так перед глазами, бесполезна, и даже вредна, так как, например, впустую отнимает силы и время на её поддержку у авторов кода. Касаемо примера выше — да, большая часть там, к сожалению, бесполезна.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	63. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от ананим on 23-Июн-11, 17:34
	>Признаюсь в том что автоматически сгенеренная документация - как правило такой же бред как автоматически сгенеренные стихи. верно. Но так же верно, что вставить в нужное место свой коммент "забывают" уж очень сильно "быдло" из кодеров. >Я бы даже сказал что нормальная документация - вкуснее таких портянок. угу. Это когда только изучаешь эту технологию. А когда ты в ней уже "живёшь", то лишний раз лезть в доки ОЧЕНЬ не хочется. А когда код соотвественно комментирован, со ссылками, мыслями, rfc, то как приятно с ним работать. >А уж если бы люди писали бы нормальную документацию и руками, а не гребаными автогенераторами - и подавно. что порой думаешь - да лучшеб сцуко не писали!! Смотришь так мсдан - должно работать, а на практике - фиг. Ну должен переменными блоками читать из компорта, ан нет... Только с левого форума узнаёшь - читай побайтово и будет тебе щастье. "Прелести" проприетарной разработки многие кодеры уже считают нормой. Что враньё.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	79. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 23-Июн-11, 18:23
	> верно. Но так же верно, что вставить в нужное место свой коммент > "забывают" уж очень сильно "быдло" из кодеров. Да не только быдло, вон там человек в общем то по делу подпинывает btrfs'ников за скудные коменты. Именно при их функционале документироать свои потуги надо бы побогаче. А XFS - 40% кода являющегося коментами все-таки перебор. Авторам в пору книгу написать - архитектура XFS. И вынести половину из коментов в нее. > Это когда только изучаешь эту технологию. А когда ты в ней уже > "живёшь", то лишний раз лезть в доки ОЧЕНЬ не хочется. Когда ты в ней уже живешь, 40% портянок вместо полезного постоянно скроллить и лицезреть должно бы подзаколебывать слегка :) > А когда код соотвественно комментирован, со ссылками, мыслями, rfc, то как приятно > с ним работать. Если вы уже живете этим кодом, 40% коментов в нем для вас явно избыточны по идее. Никто не говорит что коментить не надо, но когда почти полсырца - комент, это как-то злобно. > - должно работать, а на практике - фиг. Такое и в *никсах случается к сожалению. Особенно этим грешат всякие документы на куски POSIX и прочая, особенно допускающие неопределенность или не покрываюшие современные реалии. Там порой такая лотерея получается что впору на картах раскидывать - как на самом деле работает некая функция в той или иной системе и даже разных версиях их кернелов и системных либ. > Ну должен переменными блоками читать из компорта, ан нет... О, уарты... это в позиксах вообще довольно брейнфакерская тема. Сам с ними бодаюсь, при том по документации одно, в линях другое, макосях - третье. Да блин! А как кроссплатформенно позырить сколько в буфере байтов лежит?! А как кроссплатформенно скорость выше 115200 отхватить? Впрочем и 115200 то не везде гарантируют (чорт, неужели нельзя принять свежий позикс и зафиксировать эти моменты законодательно, чтобя я не пыжился с пачкой ifdef?). Какие-то извраты с ремапом скорости 38400. Вообще адЪ. Правда, надо сказать что в виндозе с ними все тоже довольно горбато :) > Только с левого форума узнаёшь - читай побайтово и будет тебе щастье. Дык побайтно - медленно и печально, однако. Оверхед на системные вызовы большой получается, нагрузка на систему большая а скорость работы может просесть. Кстати читать блоками при non-blocking I/O вроде более-менее получается. Правда как-то странновато, но в принципе - работает. Хоть и пришлось слепить свою функцию-враппер которая делает read() в том виде котором хотелось бы и раскинуть там энное количество костыликов. > "Прелести" проприетарной разработки многие кодеры уже считают нормой. Что враньё. Не вижу никаких особых прелестей, тем более что в виндозе с уартами тоже все довольно криво, я бы сказал. Если в *никсах хотя-бы прикладывают мордой об стол если baud не поддерживается оборудованием, то в винде вам нагло врут "зашибись!" и ... работают на старом бауде. Видали мы такие прелести!
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	83. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от ананим on 23-Июн-11, 18:43
	>Да не только быдло, вон там человек в общем то по делу подпинывает btrfs'ников за скудные коменты. оставлю это на его совести. :D >А XFS - 40% кода являющегося коментами все-таки перебор. Авторам в пору книгу написать - архитектура XFS. И вынести половину из коментов в нее. а нахрена? Разрабам ФС на это покласть, а от "новичков" кто её купит тоже ничего хорошего - устаревшие знания из такой книги нифига не догонят даже той доки (кстати очень не плохой) на вики http://xfs.org/index.php/XFS_Status_Updates и текста в комментариях >Если вы уже живете этим кодом, 40% коментов в нем для вас явно избыточны по идее. Никто не говорит что коментить не надо, но когда почти полсырца - комент, это как-то злобно. современным ИДЕ прыгать по клику мышки не привыкать. Что на 100 страницах A4, что на 60 - один клик. и мне не надо лесть чёрте куда, чтобы узнать что там за значения сможет принять вон та переменная из вон той структуры. ну а то что в доке это ещё будет и устаревшим - это к бабке не ходить.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	189. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 24-Июн-11, 23:28
	> оставлю это на его совести. :D Думаю у него совесть чиста - он в вопросе разбирается. > а нахрена? Разрабам ФС на это покласть, а от "новичков" кто её > купит тоже ничего хорошего - устаревшие знания из такой книги нифига > не догонят даже той доки (кстати очень не плохой) на вики > http://xfs.org/index.php/XFS_Status_Updates и текста в комментариях Нафига? Чтобы был ман дающий обзор общей концепции на общем уровне + наводки какие части где и как реализованы и чего смотреть. И зачем и почему реализовано именно так (на это очень редко дают ответ коменты и сгенеренные доки, но это важно для понимания как оно на самом деле должно работать). Актуальным курсом дел это не будет, но общее понимание алгоритмов и задумок - даст. А вот более тонкую синхронизацию с интересующим исходником уже естественно придется делать вкуривая оный. Только когда у вас гора манов и автогенеренный бред - концепция и вообще задумки авторов целиком как-то не очень хорошо складываются в единую стройную картину. У именно XFSников с этим еще более-менее ничего. > современным ИДЕ прыгать по клику мышки не привыкать. Что на 100 страницах > A4, что на 60 - один клик. И тем не менее, сорцы пухнут, время компила растет, сорц захламляется. > и мне не надо лесть чёрте куда, чтобы узнать что там за значения сможет принять > вон та переменная из вон той структуры. Именно такая информация в структуре как комент - да, удобно. > ну а то что в доке это ещё будет и устаревшим - это к бабке не ходить. Да и хрен с ним, задача доки дать понимание общей идеи и того что где и как реализовано, а вот конкретику реализации разумеется надо уже в сырце смотреть. А вот когда отделываются только автогенеренной докой - ну для чисто либы это может и ничего. Для ФС уже как-то не то, т.к. описание концепции и задумок автоматически не сгенерится, а без этого будет довольно сложно понять что и нафига.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	218. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Michael Shigorin (ok) on 26-Июн-11, 21:25
	> время компила растет За счёт комментариев?  Строго говоря, Вы правы, но самому не смешно ли? >> ну а то что в доке это ещё будет и устаревшим - > Да и хрен с ним Нет уж, устаревшая документация нередко хуже отсутствующей напрочь -- сбивает с толку. Ergo: когда пользуешься хорошей документацией, это чувствуется.  А рассуждать про сферическую довольно малоосмысленно.
	Ответить | Правка | ^ к родителю #189 | Наверх | Cообщить модератору

	84. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от iZEN (ok) on 23-Июн-11, 19:03
	> Когда ты в ней уже живешь, 40% портянок вместо полезного постоянно скроллить > и лицезреть должно бы подзаколебывать слегка :) Открой для себя нормальные IDE со сворачиваемым фолдингом участков комментариев.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	127. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 24-Июн-11, 01:27
	> Открой для себя нормальные IDE со сворачиваемым фолдингом участков комментариев. О, как это в стиле жабистов: сначала создать себе проблем, а потом их героически решать. Ты и про профайлеры ту же песенку пел. Конечно, можно тормознуть себя в 4 раза неэффективным рантаймом, а потом упираться для компенсации этого факта в профайлере, как ты регулярно всем советуешь. А можно просто выбросить тормозную яву и не иметь этого головняка.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	130. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–1 +/–
	Сообщение от iZEN (ok) on 24-Июн-11, 01:38
	>> Открой для себя нормальные IDE со сворачиваемым фолдингом участков комментариев. > О, как это в стиле жабистов: сначала создать себе проблем, а потом > их героически решать. Ты и про профайлеры ту же песенку пел. > Конечно, можно тормознуть себя в 4 раза неэффективным рантаймом, а потом > упираться для компенсации этого факта в профайлере, как ты регулярно всем > советуешь. А можно просто выбросить тормозную яву и не иметь этого > головняка. Преждевременные оптимизации вредны. Сначала пишем код — потом оптимизируем, разве трудно понять эту простую вещь? Примерно каждые три года удваивается объём ОЗУ среднестатистического компьютера. Так что пока ты будешь кодить на "эффективном" маложрущем C++, который не имеет бесплатных и простых инструментов профилирования, тебя удавят заказчики за несданый проект.
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	131. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+2 +/–
	Сообщение от anonymous (??) on 24-Июн-11, 01:42
	> Примерно каждые три года удваивается объём ОЗУ среднестатистического компьютера. это был пример рассуждений типичного быдлокодера. "ну и что, что у вас техника быстрее стала? нам не проблема тормознуть даже технику в пийсят раз быстрее!" > пока ты будешь кодить на "эффективном" маложрущем C++, который не имеет > бесплатных и простых инструментов профилирования жабообезьянка прочитала статью про C++ от 80-х годов прошлого века и думает, что с тех пор ничего не поменялось.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	139. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от kshetragia (ok) on 24-Июн-11, 05:46
	> это был пример рассуждений типичного быдлокодера. "ну и что, что у вас > техника быстрее стала? нам не проблема тормознуть даже технику в пийсят > раз быстрее!" К сожалению писать качественный код стало экономически не выгодно. Зачастую проще докупить железа. >> пока ты будешь кодить на "эффективном" маложрущем C++, который не имеет >> бесплатных и простых инструментов профилирования > жабообезьянка прочитала статью про C++ от 80-х годов прошлого века и думает, > что с тех пор ничего не поменялось. Для С++? Ничего-таки не поменялось. Как был УГ так и остался.
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	140. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??) on 24-Июн-11, 08:15
	> Для С++? Ничего-таки не поменялось. Как был УГ так и остался. как язык — да. а вот по поводу инструментария — не согласен: его понаделали всякого.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	158. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от ананим on 24-Июн-11, 11:07
	>Для С++? Ничего-таки не поменялось. Как был УГ так и остался. писец. Можно подумать С и С++ запрещают писать комменты по стандарту доксигенов. И с другой стороны кастрат под названием жаба без жабадоков компилится в байткод перестанет. Зыж уже народу приводили пример - дока Qt генерируется. И эта дока практически образец информативности.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	190. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 24-Июн-11, 23:29
	> К сожалению писать качественный код стало экономически не выгодно. LSE с вами не согласны :)
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	216. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Michael Shigorin (ok) on 26-Июн-11, 19:04
	> К сожалению писать качественный код стало экономически не выгодно. Ит'с эн оверстэйтмент, мэн. http://lwn.net/Articles/443775/
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	166. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 24-Июн-11, 12:29
	> Сначала пишем код — потом оптимизируем, разве трудно понять эту простую вещь? Да, конечно, сперва делаем, потом думаем. Хотя немного подумав заранее, можно избавить себя от массы проблем. Понимаешь ли, человек, иногда оптимизация сводится к "выбросить все и написать заново с нуля". Ну да, жабисты это любят, называя это рефакторингом. Я только одно не понимаю: неужели кого-то прикалывает работать заведомо на мусорный бак? > Примерно каждые три года удваивается объём ОЗУ среднестатистического компьютера. Так что > пока ты будешь кодить на "эффективном" маложрущем C++, который не имеет > бесплатных и простых инструментов профилирования, тебя удавят заказчики за несданый проект. Как это не имеет? Ты не в состоянии найти в пакетах целый выводок профайлеров? :) Правда если честно, я не особый фанат висения в профайлере. А оно как-то и не требуется, если хоть иногда включать мозг и не быдлокодить, а просто немного думать в процессе написания проги о эффективности используемого алгоритма. Выбирать первый попавшийся - удел обезьян, хватающих первую попавшуюся палку в руки.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	179. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??) on 24-Июн-11, 13:25
	> Как это не имеет? Ты не в состоянии найти в пакетах целый > выводок профайлеров? :) он даже про valgrind не знает, потому что для его жабы оно бесполезно. а если в гуголь и сходит, то наверняка заметит из всего валгринда только memcheck и будет улюлюкать про то, что «у вас даже GC нет!»
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	191. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 24-Июн-11, 23:35
	> всего валгринда только memcheck и будет улюлюкать про то, что «у > вас даже GC нет!» У него наверное даже ума собрать статистику сисколов strace'ом не хватит - такие только и могут что уповать на то что умный рантайм за них, дебилушек, подумает. Какой продукт получается в результате - нетрудно догадаться. О чем разумеется в курсе все кроме самого автора. Свое - не пахнет, да, iZEN :)
	Ответить | Правка | ^ к родителю #179 | Наверх | Cообщить модератору

	138. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от kshetragia (ok) on 24-Июн-11, 05:42
	Для нормального кода IDE не нужен. Он должен быть интуитивно понятен. Где непонятен - пара строк комментариев, которые не портят читабельность. Даже больше скажу. IDE могут быть вредны, т.к. скрыввают/смазывают представление о том как реально выглядит код и как он расположен на файловой системе.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	141. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??) on 24-Июн-11, 08:19
	> как реально выглядит код и как он расположен на файловой системе. это совершенно не важно. да и — что значит «как реально выглядит»? вон в Обероне в коде могут быть картинки, фильмы и вообще любой объект системы. и как там код «реально выглядеть» будет? кстати, советую попробовать Оберон с хорошо обработаным редактором. хотя... нет, не надо. потом остальные будут ужасно раздражать тем, что так и не вылезли до сих пор с уровня 70-х.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	167. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 24-Июн-11, 12:30
	> вон в Обероне в коде могут быть картинки, фильмы и вообще любой объект системы. Смешались в кучу кони, люди... и получилась хрень на блюде.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	176. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??) on 24-Июн-11, 13:15
	>> вон в Обероне в коде могут быть картинки, фильмы и вообще любой объект системы. > Смешались в кучу кони, люди... и получилась хрень на блюде. сразу видно Анонимного Эксперта, который не по наслышке знаком с системой Оберон.
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

	203. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 25-Июн-11, 18:37
	> сразу видно Анонимного Эксперта, который не по наслышке знаком с системой Оберон. Судя по повсеместному распостранению Оберона не так уж эксперт и неправ...
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

	227. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от kshetragia (ok) on 27-Июн-11, 07:07
	>>> вон в Обероне в коде могут быть картинки, фильмы и вообще любой объект системы. >> Смешались в кучу кони, люди... и получилась хрень на блюде. > сразу видно Анонимного Эксперта, который не по наслышке знаком с системой Оберон. Система отличная, но малораспространенная. Пока же приходится смотреть на реализации некоторых идей в других языках и пускать слюни.
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

	229. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??) on 27-Июн-11, 07:22
	> Система отличная, но малораспространенная. Пока же приходится смотреть на реализации некоторых > идей в других языках и пускать слюни. в принципе, BlackBox Component Builder открыт. вроде как даже уже есть порт ядра и линкера в пингвинус. осталась мелочь (улыбается): отвязать её от винды и привинтить заместо какой-нибуть тулкит (нененене, только не GTK, пожалуйста, что угодно, только не GTK! %-). я под винду когда-то достаточно активно на BCB писал — было очень приятно. правда, там закавыка: вроде как лицензия не позволяет делать коммерческий софт.
	Ответить | Правка | ^ к родителю #227 | Наверх | Cообщить модератору

	235. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от kshetragia (ok) on 27-Июн-11, 14:24
	действительно мелочь.
	Ответить | Правка | ^ к родителю #229 | Наверх | Cообщить модератору

	237. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??) on 27-Июн-11, 16:13
	> действительно мелочь. на крайний случай есть winelib. (убегает, увёртываясь от булыжников)
	Ответить | Правка | ^ к родителю #235 | Наверх | Cообщить модератору

	226. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от kshetragia (ok) on 27-Июн-11, 07:06
	> кстати, советую попробовать Оберон с хорошо обработаным редактором. хотя... нет, не надо. > потом остальные будут ужасно раздражать тем, что так и не вылезли > до сих пор с уровня 70-х. Как только появится свободная реализация в исходниках под Unix. И не Оберона, а Компонентного Паскаля, тогда конечно.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	230. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??) on 27-Июн-11, 07:25
	> Как только появится свободная реализация в исходниках под Unix. И не Оберона, > а Компонентного Паскаля, тогда конечно. BlackBox Component Builder. я, кстати, после открытия кода отрывал компилятор от остальной системы и даже обучал его читать обычные текстовые файлы. керналь и линкер для эльфов там тоже есть. в принципе, переписать низкоуровневый UI-код, чуть почистить — и вполне богло бы взлететь на *nix. разговоров об этом в своё время было много, но увы… правда, насчёт «свободной» не уверен: кажется, коммерческий софт на нём писать нельзя.
	Ответить | Правка | ^ к родителю #226 | Наверх | Cообщить модератору

	228. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от kshetragia (ok) on 27-Июн-11, 07:15
	>> как реально выглядит код и как он расположен на файловой системе. > это совершенно не важно. да и — что значит «как реально выглядит»? Это значит, что я должен быть в состоянии прочитать код без IDE костылей. И его размещение на файлухе является дополнительным способом структурирования кода. _Очень_ странный вопрос для Оберонщика. > вон в Обероне в коде могут быть картинки, фильмы и вообще > любой объект системы. и как там код «реально выглядеть» будет? За картинки в коде вообще нужно бить по рукам. Тем более Оберонщиков. По идее как раз у вас в крови должно быть не мешать интерфейсы с реализацией и уж тем более с данными.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	231. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??) on 27-Июн-11, 07:30
	> Это значит, что я должен быть в состоянии прочитать код без IDE > костылей. И его размещение на файлухе является дополнительным способом структурирования > кода. _Очень_ странный вопрос для Оберонщика. у оберона вообще с понятием «файл» некоторая напряжёнка. они, вроде бы, и есть, но в принципе — нафиг не нужны. и «без IDE» в обероне тупо не бывает. > За картинки в коде вообще нужно бить по рукам. Тем более Оберонщиков. > По идее как раз у вас в крови должно быть не > мешать интерфейсы с реализацией и уж тем более с данными. отчего? вполне удобно пихнуть пару диаграмок в код и спрятать в фолд. надо — открыл фолд и посмотрел. не надо — скрыл и не мешает. при передаче кому-то deep copy вполне себе всё передаст. если у него нет компонента для отображения — не страшно: покажет alien placeholder. как раз вот в обероне разрывать код и документацию я смысла не вижу совершенно.
	Ответить | Правка | ^ к родителю #228 | Наверх | Cообщить модератору

	103. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от anonymous (??) on 23-Июн-11, 22:42
	документация к Qt генерится из исходников. лучше документации я пока не видел, даже «написаной руками».
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	239. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от maginoid (ok) on 30-Июл-14, 20:30
	>> признайся сразу что ты не кодер вообще. так будет всем лучше. :D > Признаюсь в том что автоматически сгенеренная документация - как правило такой же > бред как автоматически сгенеренные стихи. То-есть, читать нормальную, писанную человеком > который шарил в вопросе - сильно быстрее, доходчивее и приятнее. На то и посажен кодер , а на пккодер.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	6. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anon8 (ok) on 23-Июн-11, 13:02
	> Проблема только в том что у XFS строк уже больше, а у btrfs фичность как-то поболее будет :))) Нуну, и что, неужели btrfs уже годна для продакшена? Фичи-фичами, а главное - стабильность.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	8. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от BratSinot on 23-Июн-11, 13:42
	А еще пряморукость. Я полностью согласен(в отношении с Btrfs) с Эдуардом Шишкиным.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	17. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от koblin (ok) on 23-Июн-11, 14:17
	Предложения, алтернативы?
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	19. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+3 +/–
	Сообщение от Аноним (??) on 23-Июн-11, 14:32
	> А еще пряморукость. Я полностью согласен(в отношении с Btrfs) с Эдуардом Шишкиным. У Шишкина было какое-то очень предвзятое мнение, наверное потому что он разработчик конкурирующего дизайна ФС. Он взял кривой юзкейс, получил кривой результат и долго плевался. Кстати, половина его плевков несмотря на едкость вполне попала в цель, и указанные слабые места были существенно затюнены/пофикшены. Соответственно, спасибо ему за тестирование этого юзкейса, хоть и далеко не основного для btrfs. В результате никому не стало хуже, а некоторым станет лучше. Что-то не так?
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	24. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 23-Июн-11, 15:12
	плевались как раз авторы btrfs
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	27. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от Аноним (??) on 23-Июн-11, 15:21
	> плевались как раз авторы btrfs Да они там на пару плевались, но в результате - тюнинг/твикинг все-таки был. Спасибо Шишкину за ругань! Половина уже стало неактуально - вот так и надо работать ;).
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	35. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от Михаил (??) on 23-Июн-11, 15:35
	Файловая система должна работать с любыми данными. Если заявила отсутствие ограничений на число файлов - будь добра обеспечить. Об этом и речь, что нет гарантии что бтрфс на конкретной структуре данных и особенностях с ними работы не сдохнет, не займёт всё место. Никто не проверял алгоритмы, на то что фрагментация гарантированно меньше некоторого значения (как в XFS например). Замечены попытки решения задач способами которые для этого не приспособлены, с вытекающими побочными эффектами. Да добавили костыль на один случай. Будут ещё. И будет код пухнуть исключениями, больше и больше. А потом чтобы разобраться в бардаке и восстановить данные оракл потребует у корпораций миллиарды :)
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	67. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+2 +/–
	Сообщение от Аноним (??) on 23-Июн-11, 17:43
	> Файловая система должна работать с любыми данными. Если заявила отсутствие ограничений > на число файлов - будь добра обеспечить. У них раньше было ограничение прямо в утилитах - они посылали при попытке создать том менее 2 Гб. Шишкин создал 600Мб и завалил его мелкими файлами. Получив вполне предсказуемый результат. > Об этом и речь, что нет гарантии что бтрфс на конкретной структуре > данных и особенностях с ними работы не сдохнет, не займёт всё место. В сложной конфигурации вам вообще никто ничего и никогда не гарантирует. XFS в частности хорош лишь для больших нефрагментированных файлов. На куче мелочи он вообще зверски тормознут. В последних версиях ядра (в районе 37..39 ядер чтоли) это подтянули слегка правда, стало более-менее похоже на остальные типа EXT4/JFS/... даже. > Никто не проверял алгоритмы, на то что фрагментация гарантированно меньше > некоторого значения (как в XFS например). Теория - это прекрасно. Проблема только в том что если не миндальничать и взять дейстивтельно негуманный сценарий, например, забить XFSный том до упора торентами с мелкими блоками, слитыми без преаллокации - сдуется он точно так же как и любая другая ФС. И толку с теоретизирований будет немного. Все-равно без дефрагментации будет неюзабельно. Когда диск выдающий на крайних треках 150Мб/сек натужно шуршит, выдавая 10Мб/сек при последовательном чтении файла - толку то с ваших теоретических гарантий? На практике - Ж! > Замечены попытки решения задач способами > которые для этого не приспособлены, с вытекающими побочными эффектами. А именно? И конечно же вы, или Шишкин готовы предложить более хорошее по параметрам решение? Или вы/Шишкин/кто там еще готовы создать решение лучше и гарантировать что оно во всех ворклоадах сделает btrfs? Если посмотреть на реальные бенчи - btrfs довольно злая штука и зачастую всех натягивает. При этом успевая честный журналинг данных, чего XFS не только не делает, но раньше еще и тер сомнительные места в данных нулями. Знаете как круто когда вам кусок базы данных нулями протрут и однажды все резко наворачивается? :) > Да добавили костыль на один случай. Будут ещё. И будет код пухнуть > исключениями, больше и больше. Функционала у btrfs намного больше. Там уже управление томами в пуле есть, фоновый дефраг, ребаланс, CoW и при этом у них почему-то до сих пор меньше строк кода. Напрашивается вывод что код у них в целом довольно эффективный. > А потом чтобы разобраться в бардаке и восстановить данные оракл потребует у корпораций миллиарды :) Для начала, CoW не убивает данные при перезаписи. И кстати кто оплатит протертые нулями XFSом файлы?Есть желающие? :) Вообще, файловые системы которые вы противопоставляете - очень разные по функционалу. Ну например у XFS нет снапшотов. И перезапись - разрушающая. И полного журналирования - нет (спасибо что хоть вытирание нулями спорных кусков удавили). И фоновый дефраг/ребаланс и прозрачное добавление диска в пул с XFS не сделаешь. XFS это "просто еще одна ФС". А btrfs это такой комплексный комбайн. К слову довольно прилично надирающий зад и в режиме "якобы мы тут простая ФС".
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	16. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от Аноним (??) on 23-Июн-11, 14:14
	> Нуну, и что, неужели btrfs уже годна для продакшена? Еще не годна. Но неотвратимо приближается к этому моменту. > Фичи-фичами, а главное - стабильность. В продакшне? Разумеется. Но это не значит что не надо идти вперед. К слову, у XFS довольно плохая история заботы о сохранности пользовательских данных с ее затиранием нулями в случае краха в момент записи. А вот btrfs в этом плане должен быть напротив очень хорош, архитектурно у него для этого все карты на руках.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	105. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??) on 23-Июн-11, 22:54
	> годна для продакшена? что значат эти слова? винда вон нестабильна даже при штатном использовании без хаков — а считается «готовой для продакшэна».
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	108. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 23-Июн-11, 23:10
	>> годна для продакшена? > что значат эти слова? винда вон нестабильна даже при штатном использовании без > хаков — а считается «готовой для продакшэна». Винда стабильна или нестабильна при штатном использовании точно так же, как любая другая серьёзная ОС. Косяков в ней хватает, никто не спорит. Но и работать годами без сбоев она тоже умеет. Бубны везде свои просто.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	168. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 24-Июн-11, 12:33
	Да какой там бубен, если видеодрайвера падают? Ты или пользуешься футуристичной VESA видеокартой, или миришься с тоннами глюков а то и просто дедлоков. А каким бубном ты исправишь глючный видеодрайвер? Даже если б ты это захотел, сырцов нет, а колупать многомеговую портянку дизассемблером - крайне малоперспективно, тем более что для защиты от модификаций там все подписями нынче обложено от и до.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	183. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 24-Июн-11, 13:54
	> Да какой там бубен, если видеодрайвера падают? Ты или пользуешься футуристичной VESA > видеокартой, или миришься с тоннами глюков а то и просто дедлоков. > А каким бубном ты исправишь глючный видеодрайвер? Даже если б ты > это захотел, сырцов нет, а колупать многомеговую портянку дизассемблером - крайне > малоперспективно, тем более что для защиты от модификаций там все подписями > нынче обложено от и до. Видеокарты нормальные используйте. Или кроме ATI (AMD) и NVIDIA других названий не знаете? В моём продакшене видеокарты вообще в большинстве случаев побоку, более того, Win2003+ даже последовательную консоль какую-никакую заимел нормальную — необходимости в видеокарте попросту нет. К слову, видеодрова в других ОС глючат ничуть не меньше. С той оговоркой, что винда отвечает лишь за свои родные дрова, а не то г..., которое качают с сайтов производителей. А насчёт колупания дизассемблером — не в кассу. Хотите ковыряться в дровах — используйте другие ОС, никто не запрещает. Я лично только поприветствую. Просто не надо со своим уставом в чужой монастырь, ку? :)
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

Часть нити удалена модератором

	193. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 25-Июн-11, 00:12
	> Видеокарты нормальные используйте. Или кроме ATI (AMD) и NVIDIA других названий не знаете? Почему же, знаем встроенные в интелские чипсеты еще. Вообще тормозная гадость. С не менее гадостными драйверами, запросто вешающими систему. Кстати дрова для серверных мамок от интела под винду - вообще жуткий вырвиглаз. Мало того что все часто упихано в монолитный EXE инсталлер, так он еще и обламывается установить дрова как только условия хоть на миллиметр отличаются от идеала. Лишний хотфикс или не да - и вот уже инсталлер говорит что винда не та. Круто придумано. > необходимости в видеокарте попросту нет. Как бы тянуть отдельный шнур до сервера - совершенно не прикольно. В нормальных осях есть ssh а на случай когда приперло - можно и по сетке отсигналить ядру наконец, если сервер в труднодоступном месте а что-то идет не так и юзермод настолько сдох что ssh уже не работает (при постоянном out of memory такое бывает, например). > К слову, видеодрова в других ОС глючат ничуть не меньше. По-моему, под семерку/висту (ну и 2008) одни из наиболее глючных дров из всех ос вообще. Правда вот на серверных ОС видеодрайвера почти не у дел и с чего б им глючить, если 99% времени никто не то что ничего не делает а даже в монитор не смотрит? А если попользоваться - найти чертыхания юзеров висты/7/2008 совершенно не проблема. > С той оговоркой, что винда отвечает лишь за свои родные дрова, Судя по тому как работают эти драйвера - они там вообще ни за что не отвечают. Они только формально лепят подпись. Все. В результате амдшные дрова - глючат как хотят и тормознее официальных амдшных чуть ли не в два раза. Где они это вообще берут? Интел - аналогично. Очень нестабильные и падучие драйвера. С подписью майкрософт. На нвидию тоже бочки катят периодически. Кстати в XP/2003 с этим получше было. В семерке/висте для благой цели укрепления DRM драйвера переделали, производители в спешке писали ну хоть что-нибудь к выходу висты. Понятно что и как написали. И главное - как пользователь я не вижу что мне это все дает кроме геморроя. > а не то г..., которое качают с сайтов производителей. Субъективно у MS такое же г... как и на сайте производителей. Можно подумать, они сами пишут дрова. Они лепят свою подпись на какую-то античную версию дров производителя, и вот уже встроенный в винды драйвер готов. Такое же г, только еще и окаменелое. > Просто не надо со своим уставом в чужой монастырь, ку? :) Ну так и не лезьте.Идите на MSDN и лечите там какие замечательные у MS дрова. Там вас поймут.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	196. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 25-Июн-11, 02:34
	>> Видеокарты нормальные используйте. Или кроме ATI (AMD) и NVIDIA других названий не знаете? > Почему же, знаем встроенные в интелские чипсеты еще. Вообще тормозная гадость. С > не менее гадостными драйверами, запросто вешающими систему. Кстати дрова для серверных > мамок от интела под винду - вообще жуткий вырвиглаз. Мало того > что все часто упихано в монолитный EXE инсталлер, так он еще > и обламывается установить дрова как только условия хоть на миллиметр отличаются > от идеала. Лишний хотфикс или не да - и вот уже > инсталлер говорит что винда не та. Круто придумано. Второй ноутбук с Intel'ом на борту. В винде проблем нет вообще. В X.org есть небольшой глюк при переключении консолей (кто там виноват, дрова или Иксы, точно сказать не могу), в целом всё стабильно. Может, конечно, просто потому, что мой продакшн, как я уже говорил, не завязан сильно на видеоподсистеме? :) И, повторюсь, винда тут абсолютно ни при чём. Траблы с видеодрайверами есть везде. >> необходимости в видеокарте попросту нет. > Как бы тянуть отдельный шнур до сервера - совершенно не прикольно. А что, VGA/DVI-шнур чем-то лучше? > В нормальных осях есть ssh Никто не мешает его ставить в винде. Более того, в винде есть RDP (сюрприз!), а также можно поставить VNC, RAdmin, NX... > а на случай когда приперло - можно > и по сетке отсигналить ядру наконец, если сервер в труднодоступном месте > а что-то идет не так и юзермод настолько сдох что ssh > уже не работает (при постоянном out of memory такое бывает, например). Вот когда SSH не работает, и вообще совсем плохо, и нужна последовательная консоль. Учите матчасть, что ли... >> К слову, видеодрова в других ОС глючат ничуть не меньше. > По-моему, под семерку/висту (ну и 2008) одни из наиболее глючных дров из > всех ос вообще. Правда вот на серверных ОС видеодрайвера почти не > у дел и с чего б им глючить, если 99% времени > никто не то что ничего не делает а даже в монитор > не смотрит? Браво, до вас начало доходить. > А если попользоваться - найти чертыхания юзеров висты/7/2008 совершенно > не проблема. Да. Равно как и чертыхания пользователей других ОС. >> С той оговоркой, что винда отвечает лишь за свои родные дрова, > Судя по тому как работают эти драйвера - они там вообще ни > за что не отвечают. Они только формально лепят подпись. Вообще-то да, не отвечают. Драйвера для большинства (если не всех) современных видеокарт делают производители. Microsoft предоставляет необходимые спецификации (WHQL), если драйвер им удовлетворяет - велкам. Драйвера, идущие вместе с ОС, обычно тестируют лучше прочих, но и функционал при этом у них зачастую урезанный в целях надёжности. Сбой в драйвере - практически всегда оказывается на совести его разработчика. Родные драйвера MS - это, например, драйвер SCSI-контроллера. Который взаимодействует с т.н. драйвером минипорта. Который в свою очередь уже предоставляется обычно производителем контроллера. MS и Windows - мишени крупные, промахнуться сложно. Но вы всё же умудрились это сделать. :) > Все. В > результате амдшные дрова - глючат как хотят и тормознее официальных амдшных > чуть ли не в два раза. Где они это вообще берут? > Интел - аналогично. Очень нестабильные и падучие драйвера. С подписью майкрософт. Эта подпись всего лишь удостоверяет, что MS действительно дала вам эти дрова. Не путайте тёплое с мягким, а автора - с издателем. > На нвидию тоже бочки катят периодически. Кстати в XP/2003 с этим > получше было. В семерке/висте для благой цели укрепления DRM драйвера переделали, > производители в спешке писали ну хоть что-нибудь к выходу висты. Понятно > что и как написали. И главное - как пользователь я не > вижу что мне это все дает кроме геморроя. Угу. В спешке. Идеи, организовавшиеся в Vista, к слову, начали прорабатывать ещё в девяностых. Технические спецификации и альфа-версии были доступны для крупных вендоров как минимум за год до релиза. Пинайте производителей железок, в подавляющем большинстве случаев косячат они. Упреждая вопрос, откуда я, опёнковод с семилетним стажем, это знаю? Да просто интересуюсь много чем. Кроме разве что 3D-игр... >> а не то г..., которое качают с сайтов производителей. > Субъективно у MS такое же г... как и на сайте производителей. Можно > подумать, они сами пишут дрова. Они лепят свою подпись на какую-то > античную версию дров производителя, и вот уже встроенный в винды драйвер > готов. Такое же г, только еще и окаменелое. Что им производитель даёт, то они и лепят. Попутно отрезая всё нестабильно работающее. Хотите понтов и скорости - идите на поклон к разработчику железки. >> Просто не надо со своим уставом в чужой монастырь, ку? :) > Ну так и не лезьте.Идите на MSDN и лечите там какие замечательные > у MS дрова. Там вас поймут. Вы лезете с опенсорсным миропониманием (к слову, весьма узким) в пропиетарный мир. Это выглядит смешно. Если вам просто надо доказать, что вы знаете Великую Истину Про Плохой Виндоус, доказывайте её виндузятникам. А я уже жалею, что потратил на вас время, скорее всего, это было впустую. Что ж, тоже наука. :)
	Ответить | Правка | ^ к родителю #193 | Наверх | Cообщить модератору

	204. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 25-Июн-11, 19:33
	> Второй ноутбук с Intel'ом на борту. В винде проблем нет вообще. Не знаю как там у вас нет проблем, а я регулярно наталкиваюсь на взвисы семерок и вист на интеловских чипсетах. Обычно графика виснет настолько, что помогает только reset или там где его нет (ноуты) - power button на 4 sec. Особенно характерно для входа-выхода hibernate/powersave режимы, там вообще шансы на взвис видео чуть ли не 50/50, особенно с интелом как раз. > В X.org есть небольшой глюк при переключении консолей (кто там виноват, дрова > или Иксы, точно сказать не могу), Не заметил никаких проблем с переключением консолей. Как минимум в убунте с ее фреймбуферными консолями - все отлично. И вообще, интеловский драйвер может месяц непрерывно отпахать без ребутов. При просмотре фильмов, использовании 3D в играх и что там еще. Выводы напрашиваются. > в целом всё стабильно. Может, конечно, просто потому, что мой продакшн, > как я уже говорил, не завязан сильно на видеоподсистеме? :) А если компьютер вообще выключить - он уж наверняка глючить не сможет. Какой смысл обсуждать глюкавость железки, если она не используется? > И, повторюсь, винда тут абсолютно ни при чём. Траблы с видеодрайверами есть везде. Они есть везде, но некоторые из них не чинятя годами. В частности это касается интеловских дров для висты и семерки. >>> необходимости в видеокарте попросту нет. >> Как бы тянуть отдельный шнур до сервера - совершенно не прикольно. > Никто не мешает его ставить в винде. ..кроме того момента что винда довольно плохо через него управляется. Она никогда не затачивалась на такое применение. Не верите? Да блин, попробуйте через ssh настройки сетевого адаптера прописать? А сможете точку доступа из вай-фай адаптера через него переконфигурять? Чтобы уж совсем хорошо? Ну и толку от такого SSH? Это не шелл, это борьба с искусственными проблемами. > Более того, в винде есть RDP (сюрприз!), ...только при умирании графики он как ни странно обычно тоже умирает. Как правило, при сбое графики он показывает логон-скрин. Далее прогресс логона. Все - на этой фазе он остается навсегда. Вроде бы система и не полный труп, но даже корректный шатдаун там сделать - очень сложно. > а также можно поставить VNC, RAdmin, NX... Можно. Только оно нагружает проц и сеть намного сильнее + не очень хорошо переживает сбои + второе очень часто детектится антивирусами как малварь. В сумме гемора получается выше крыши. > Вот когда SSH не работает, и вообще совсем плохо, и нужна последовательная > консоль. Учите матчасть, что ли... Ни разу не видел придурков которые бы развлекались тем что от серверов сериальные шнурки бы тянули, это требует необоснованных затрат на проводку. При наличии уже проложенного эзернет-шнурка это жуткий маразм. Тем более что кернелу не так уж принципиально, работать с сетью или с сериальным шнурком. И как минимум линух можно обучить реагировать на alt-sysrq-* и по сети, как раз в случае если серверу очень плохо, а физически к нему лезть неудобно. Так удается выводить из штопора даже машины где ssh по какой-то причине не может взлететь (например, постоянный OOM не дающий форкнуть новый процесс + oom_killer почему-то не смог разрулить проблему). > Браво, до вас начало доходить. Да. Если компьютер выключить - то он вообще глючить не будет. Вывод: WinME - прекрасная система. Если компьютер с ней не включать. > Да. Равно как и чертыхания пользователей других ОС. Тем не менее, позволю себе еще 1 пример: если надо чтобы usb-девайс, например FTDI232, работал долго и в автопилотном режиме, линукс выглядит намного перспективнее. В винде оно иногда может отвалиться и .. все. До физического передерга девайса связи не будет. В линухе - оно для начала не отваливается. Однако если при работе с юсб-девайсами что-то идет не так, у пингвина хватает ума сделать "виртуальный передерг" устройства, вправив ему мозг ресетом по шине. Аналогично - SATA линки и прочая. Можно конечно долго бухтеть что глючным железом пользоваться не надо, однако если вопрос пойдет о том чтобы сколько-то девайсов сколько-то лет работало без людей, окажется что все гораздо сложнее и раз в год даже кабель питания глючит :). Мало ли, какие-то мощные помехи на кабель собирются, или там что еще. В таком случае винде нечем похвастать. > делают производители. Тогда к чему была реклама MS? К тому что с S3 Virge DX оно работает без глюков? У меня и на нем глюки в свое время были. > Microsoft предоставляет необходимые спецификации (WHQL), если > драйвер им удовлетворяет - велкам. По факту, MS вообще ничего толком не тестирует. Случаи разворота на тестированиях крайне редки. По факту этот набор букв ничего не значит. Всего лишь глупый понт чтобы хоть немного оправдать необходимость лепить подписи и прикрыть свое неприкрытое желание рулить производителями железа. > Драйвера, идущие вместе с ОС, обычно тестируют лучше прочих, Малозаметно. Во всяком случае, у висты/семерки с этим предостаточно проблем. > но и функционал при этом у них зачастую урезанный в целях надёжности. Не заметил никакой особой надежности у хоть того же интеловского видеодрайвера из семерки. Видео он кладет на раз, вплоть до взвиса машины. > Сбой в драйвере - практически всегда оказывается на совести его разработчика. Я уже заметил - не важно что и где случается, майкрософт никогда не виноват. Интересно, а вот по поводу такого бага http://support.microsoft.com/kb/2249857 вы их сможете отмазать? В баге который разносит на куски файловую систему на диске - тоже сторонние производители виноваты? :) > Родные драйвера MS - это, например, драйвер SCSI-контроллера. Который взаимодействует > с т.н. драйвером минипорта. Который в свою очередь уже предоставляется обычно > производителем контроллера. Да, вон там повыше пример для родных драйверов и утилит майкрософта. При записи крешдампа на том более 2Тб том оказывается попросту угроблен и не восстанавливается простыми методами - вместо файловой системы вермишель получается. Очень интересно как вы отмажете MS в этот раз. > MS и Windows - мишени крупные, промахнуться сложно. Но вы всё же > умудрились это сделать. :) Мы добавим, нам не сложно. > Эта подпись всего лишь удостоверяет, что MS действительно дала вам эти дрова. > Не путайте тёплое с мягким, а автора - с издателем. Правда учтя что мсовские драйвера могут убить диск - не очень понятно какие есть основания доверять их кривулькам больше чем всем остальным. > большинстве случаев косячат они. Еще-бы, большая часть дров писана ими - логично что и большую часть глюков они привнесут. Если не писать код - то и багов в нем не будет. MS впрочем вон как-то умудрился багов насажать даже без сильных изменений кода ядра. > Упреждая вопрос, откуда я, опёнковод с семилетним стажем, это знаю? Да просто > интересуюсь много чем. Кроме разве что 3D-игр... Спасибо за лишнее подтверждение того что пользватели BSD - это такие замаскированные под пенек виндузятники. > Что им производитель даёт, то они и лепят. Какая мне как пользователю разница, кто там из них облажался?! Я хочу чтобы железо работало и не требовало моего внимания. В линуксе все чаще это именно так. В винде тенденция обратная в последнее время. > Попутно отрезая всё нестабильно работающее. Хотите понтов и скорости - идите > на поклон к разработчику железки. В конечном итоге получается что глюки что так что эдак, насажал их производитель, чинить их он не собирается зачастую, и единственное что вы как пользователь можете -  пожаловаться в ООН. > Вы лезете с опенсорсным миропониманием (к слову, весьма узким) в пропиетарный мир. Я всего лишь сравниваю. И если сравнение не в пользу проприетарщиков - тем хуже для них. В моем понимании, драйвер - это такой бесплатный придаток к железке. Техническая сущность, нужная чисто для того чтобы железка у меня могла бы работать. Покупаю я железку, а драйвер - неизбежное зло. Попытки зажимать спеки/сорц драйвера намекают на то что производитель собирается прокатить пользователя в духе фирмы Сони. > жалею, что потратил на вас время, скорее всего, это было впустую. Ничего, зато набили руку в напевании дифирамбов. Идите вон на MSDN, там вас поймут.
	Ответить | Правка | ^ к родителю #196 | Наверх | Cообщить модератору

	212. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 26-Июн-11, 00:41
	>> Второй ноутбук с Intel'ом на борту. В винде проблем нет вообще. > Не знаю как там у вас нет проблем, а я регулярно наталкиваюсь > на взвисы семерок и вист на интеловских чипсетах. Обычно графика виснет > настолько, что помогает только reset или там где его нет (ноуты) > - power button на 4 sec. Особенно характерно для входа-выхода hibernate/powersave > режимы, там вообще шансы на взвис видео чуть ли не 50/50, > особенно с интелом как раз. Ну так не используйте Intel. В чём проблема? Вы что, решили, что я вас агитирую? Да ни в жисть. В этом треде занимаетесь агитацией только вы, а точнее - чёрным пиаром. И то, что вы это делаете, вполне возможно, бескорыстно, ничего не меняет. >> В X.org есть небольшой глюк при переключении консолей (кто там виноват, дрова >> или Иксы, точно сказать не могу), > Не заметил никаких проблем с переключением консолей. Как минимум в убунте с > ее фреймбуферными консолями - все отлично. И вообще, интеловский драйвер может > месяц непрерывно отпахать без ребутов. При просмотре фильмов, использовании 3D в > играх и что там еще. Выводы напрашиваются. Искренне рад за вас. >> в целом всё стабильно. Может, конечно, просто потому, что мой продакшн, >> как я уже говорил, не завязан сильно на видеоподсистеме? :) > А если компьютер вообще выключить - он уж наверняка глючить не сможет. > Какой смысл обсуждать глюкавость железки, если она не используется? А если отучиться передёргивать, то можно за адекватного человека сойти. Более глупо выглядят разве что аналогии между цифровым и реальным миром, когда начинают говорить о воровстве. >> И, повторюсь, винда тут абсолютно ни при чём. Траблы с видеодрайверами есть везде. > Они есть везде, но некоторые из них не чинятя годами. В частности > это касается интеловских дров для висты и семерки. Драйвера под другие ОС, повторюсь, не лучше. Вы сами себе противоречите: сначала доказываете мне, что, мол, один мой частный случай ничего не значит, а вот у вас та-а-акие глюки были на винде. А потом наоборот, приводите свой частный случай в другой ОС. Бездарный троллинг. User294 обычно лучше это делал, я по нему уже прямо-таки скучаю. >>>> необходимости в видеокарте попросту нет. >>> Как бы тянуть отдельный шнур до сервера - совершенно не прикольно. >> Никто не мешает его ставить в винде. > ..кроме того момента что винда довольно плохо через него управляется. Она никогда > не затачивалась на такое применение. Не верите? Да блин, попробуйте через > ssh настройки сетевого адаптера прописать? А сможете точку доступа из вай-фай > адаптера через него переконфигурять? Чтобы уж совсем хорошо? Ну и толку > от такого SSH? Это не шелл, это борьба с искусственными проблемами. Через SSH - легко. Про ipconfig рассказать? Насчёт "точку доступа из вай-фай адаптера через него переконфигурять" не совсем понятно, что имелось в виду: то ли что сетевой адаптер работает как точка доступа, то ли что надо до точки доступа достучаться через сетевой адаптер, к компу с которым сделано подключение по SSH... В любом случае всё это через SSH делается. Просто по-другому, чем в *nix. И, к слову, этот разговор не имеет ни малейшего отношения к вопросу о видеодрайверах. >> Более того, в винде есть RDP (сюрприз!), > ...только при умирании графики он как ни странно обычно тоже умирает. Как > правило, при сбое графики он показывает логон-скрин. Далее прогресс логона. Все > - на этой фазе он остается навсегда. Вроде бы система и > не полный труп, но даже корректный шатдаун там сделать - очень > сложно. Вы это кому рассказываете, а? Я же, по-вашему (см. ниже) латентный виндузятник, и по определению должен знать недостатки своей системы лучше вас как линуксоида, м-м-м? ;) >> а также можно поставить VNC, RAdmin, NX... > Можно. Только оно нагружает проц и сеть намного сильнее + не очень > хорошо переживает сбои + второе очень часто детектится антивирусами как малварь. > В сумме гемора получается выше крыши. Во-первых, VNC при должной настройке работает вполне пристойно. И не забываем, что есть далеко не одна реализация оного. Во-вторых, если уж мы говорим о продакшене, то можем говорить и о нормальных антивирусах, обученных делать исключения. В-третьих, гимор будет всегда. С любым решением. Весь вопрос, какое решение наименее гиморное. >> Вот когда SSH не работает, и вообще совсем плохо, и нужна последовательная >> консоль. Учите матчасть, что ли... > Ни разу не видел придурков которые бы развлекались тем что от серверов > сериальные шнурки бы тянули, это требует необоснованных затрат на проводку. Во-первых, за придурка и ответить можно. ;) Во-вторых, вы куда его тянуть собрались? Всё решается в пределах стойки. Ну не понимаете вы о чём речь, так и скажите. > При наличии уже проложенного эзернет-шнурка это жуткий маразм. Тем более что кернелу > не так уж принципиально, работать с сетью или с сериальным шнурком. > И как минимум линух можно обучить реагировать на alt-sysrq-* и по > сети, как раз в случае если серверу очень плохо, а физически > к нему лезть неудобно. Так удается выводить из штопора даже машины > где ssh по какой-то причине не может взлететь (например, постоянный OOM > не дающий форкнуть новый процесс + oom_killer почему-то не смог разрулить > проблему). А если у вас проблемы с сетью? DDoS-атака, глючный драйвер сети, сошедший с ума или ошибочно сконфигурированный фаервол... А RS-232 туп как пробка и работает везде. Через него можно (а подчас - единственно возможно) вести отладку ядра, между прочим. А что касается Ethernet, вы о некоторых интересных технологиях, похоже, и не в курсе. Потому что то, что вы описали, где-то на уровне если не каменного века, то до изобретения пороха точно. >> Браво, до вас начало доходить. > Да. Если компьютер выключить - то он вообще глючить не будет. Вывод: > WinME - прекрасная система. Если компьютер с ней не включать. Про передёргивания см. выше. >> Да. Равно как и чертыхания пользователей других ОС. > Тем не менее, позволю себе еще 1 пример: если надо чтобы usb-девайс, > например FTDI232 <...> Ну какое, какое отношение это имеет к видеодрайверам?! Вы хотите мне доказать, что Linux круче винды? ЗАЧЕМ?! Во-первых, всё равно не докажете - я буду использовать подходящий инструмент, будь то *BSD, Linux, Windows или вообще FreeRTOS. И у меня всё будет работать. А у вас, боюсь, будут описанные вами проблемы. >> делают производители. > Тогда к чему была реклама MS? Где я рекламировал MS? Или рекламой считается тыканье собеседника в его, гм, ошибки? > К тому что с S3 Virge > DX оно работает без глюков? У меня и на нем глюки > в свое время были. 1. Я ничего не говорил про S3. 2. Вообще то было сильно глючное железо само по себе, и я слабо понимаю, с чего вы приписываете мне утверждение его как эталона надёжности. Кстати, да, вы не слышали никогда, что иногда виноват не драйвер, и не ОС, а сама железяка, которая не соответствует собственным спецификациям? Но это так, к слову... >> Microsoft предоставляет необходимые спецификации (WHQL), если >> драйвер им удовлетворяет - велкам. > По факту, MS вообще ничего толком не тестирует. Случаи разворота на тестированиях > крайне редки. По факту этот набор букв ничего не значит. Всего > лишь глупый понт чтобы хоть немного оправдать необходимость лепить подписи и > прикрыть свое неприкрытое желание рулить производителями железа. Почитайте сначала, что такое WHQL, а? В эти тесты НЕ ВХОДИТ тестирование корректности работы драйверов с железом! Только корректность взаимодействия драйвера и подсистем Windows. Прохожение WHQL-сертификации не подразумевает выявление ошибок в коде драйвера как таковых. >> Драйвера, идущие вместе с ОС, обычно тестируют лучше прочих, > Малозаметно. Во всяком случае, у висты/семерки с этим предостаточно проблем. Я так понимаю, ваш пример ниже, там и ответ. И всё-таки перечитайте, что я написал выше: за эти драйвера отвечает производитель. Можете выставить претензии MS, что они должны тестировать поставляемые производителем драйвера на всё выпускаемое этим же производителем железо... >> но и функционал при этом у них зачастую урезанный в целях надёжности. > Не заметил никакой особой надежности у хоть того же интеловского видеодрайвера из > семерки. Видео он кладет на раз, вплоть до взвиса машины. !"№;%:? Какое отношение имеет интеловский драйвер к самой ОС? Вы б ещё на винду за некачественные прошивки для каких-нибудь вайфай-карточек, идущих с этими драйверами, наехали. >> Сбой в драйвере - практически всегда оказывается на совести его разработчика. > Я уже заметил - не важно что и где случается, майкрософт никогда > не виноват. Интересно, а вот по поводу такого бага http://support.microsoft.com/kb/2249857 > вы их сможете отмазать? В баге который разносит на куски файловую > систему на диске - тоже сторонние производители виноваты? :) Ничего хорошего я там не вижу. Чего вы от меня ждали-то? Почему я должен отмазывать винду? Потому что вы сочли меня фанатом винды? И снова: какое отношение это имеет к видеодрайверам? >> Родные драйвера MS - это, например, драйвер SCSI-контроллера. Который взаимодействует >> с т.н. драйвером минипорта. Который в свою очередь уже предоставляется обычно >> производителем контроллера. > Да, вон там повыше пример для родных драйверов и утилит майкрософта. При > записи крешдампа на том более 2Тб том оказывается попросту угроблен и > не восстанавливается простыми методами - вместо файловой системы вермишель получается. > Очень интересно как вы отмажете MS в этот раз. Отмазывайте сами, если это вам так нужно. К драйверам видеокарт и вообще железа приведённый вами пример не имеет никакого отношения. >> MS и Windows - мишени крупные, промахнуться сложно. Но вы всё же >> умудрились это сделать. :) > Мы добавим, нам не сложно. Угу. Только вы при этом убежали за пределы поля. Там вы можете хоть мяч руками хватать, только на счёт это никак не повлияет. >> Эта подпись всего лишь удостоверяет, что MS действительно дала вам эти дрова. >> Не путайте тёплое с мягким, а автора - с издателем. > Правда учтя что мсовские драйвера могут убить диск - не очень понятно > какие есть основания доверять их кривулькам больше чем всем остальным. 1. Строго говоря, не диск, а раздел. 2. Никто не просит доверять. Речь шла о том, кто несёт ответственность за кривые драйвера на видеокарты и вообще железо. Вы почему-то начали утверждать, что MS, хотя MS как раз имеет мало отношения к данным случаям. >> большинстве случаев косячат они. > Еще-бы, большая часть дров писана ими - логично что и большую часть > глюков они привнесут. Если не писать код - то и багов > в нем не будет. MS впрочем вон как-то умудрился багов насажать > даже без сильных изменений кода ядра. Баги есть у всех. У Windows, у Linux, у *BSD и у FreeRTOS. >> Упреждая вопрос, откуда я, опёнковод с семилетним стажем, это знаю? Да просто >> интересуюсь много чем. Кроме разве что 3D-игр... > Спасибо за лишнее подтверждение того что пользватели BSD - это такие замаскированные > под пенек виндузятники. Чуть повторюсь: вы божественно предсказуемы в своих потугах на сарказм. Это было бы смешно, если бы не было так печально. >> Что им производитель даёт, то они и лепят. > Какая мне как пользователю разница, кто там из них облажался?! Я хочу > чтобы железо работало и не требовало моего внимания. В линуксе все > чаще это именно так. В винде тенденция обратная в последнее время. Вы как-нибудь определитесь, кто вы: пользователь или сисадмин. Пользователь ест, что дают. Админ может выбрать то, что ему больше подходит. Если вы так часто едите кактусы, то таки да, вы просто пользователь. Но тогда не беритесь рассуждать о том, в чём не разбираетесь. В том числе о драйверах, устройстве ОС, способах удалённого управления компьютерами... А если же вы претендуете на то, чтобы быть спецом, то и ведите себя адекватно. Иначе грош вам цена, с вашей звёздной болезнью под названием "а у меня Linux работает". >> Попутно отрезая всё нестабильно работающее. Хотите понтов и скорости - идите >> на поклон к разработчику железки. > В конечном итоге получается что глюки что так что эдак, насажал их > производитель, чинить их он не собирается зачастую, и единственное что вы > как пользователь можете -  пожаловаться в ООН. Ну и зачем вы это мне (и остальным) рассказываете-то? >> Вы лезете с опенсорсным миропониманием (к слову, весьма узким) в пропиетарный мир. > Я всего лишь сравниваю. И если сравнение не в пользу проприетарщиков - > тем хуже для них. В моем понимании, драйвер - это такой > бесплатный придаток к железке. Техническая сущность, нужная чисто для того чтобы > железка у меня могла бы работать. Покупаю я железку, а драйвер > - неизбежное зло. Попытки зажимать спеки/сорц драйвера намекают на то что > производитель собирается прокатить пользователя в духе фирмы Сони. Лучше б производители давали спеки разработчикам ОС, а не драйвера... Эх, мечты, мечты. >> жалею, что потратил на вас время, скорее всего, это было впустую. > Ничего, зато набили руку в напевании дифирамбов. Идите вон на MSDN, там > вас поймут. Покажите мне хоть один дифирамб. Пока что агитацией, повторюсь, занимаетесь только вы, доказывая, что Linux - это круто, а Windows - отстой. Я говорил лишь о том, кто несёт ответственность за определённые проблемы. Перечитайте ещё раз нашу с вами беседу и убедитесь. Засим прошу простить, но мне пора заниматься более важными делами. Можете поплевать вслед, я это уже не увижу - к счастью, на опеннете можно отписаться от новых комментов. :)
	Ответить | Правка | ^ к родителю #204 | Наверх | Cообщить модератору

	219. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Michael Shigorin (ok) on 26-Июн-11, 21:38
	> Никто не мешает его ставить в винде. Более того, в винде есть > RDP (сюрприз!), а также можно поставить VNC, RAdmin, NX... Вроде бы речь шла про серверную часть -- удивился, заглянул на nomachine.com, NX-сервер под винду и макось продолжаю не наблюдать.
	Ответить | Правка | ^ к родителю #196 | Наверх | Cообщить модератору

	232. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от ананим on 27-Июн-11, 08:17
	более того, в никсах тоже есть xrdp (это я про сервер). И нормально работающие кстати. Даже могут кок прокси выступать для vnc и пр.
	Ответить | Правка | ^ к родителю #219 | Наверх | Cообщить модератору

	180. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??) on 24-Июн-11, 13:28
	а я не про это говорил. я хотел узнать, что значит «годно для продакшена». а то многие это словосочетание используют, а никто не может пояснить, что же оно значит. ну, кроме «трололо».
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	197. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 25-Июн-11, 02:37
	> а я не про это говорил. я хотел узнать, что значит «годно > для продакшена». а то многие это словосочетание используют, а никто не > может пояснить, что же оно значит. ну, кроме «трололо». У каждого свой продакшн, и своя правда. Nothing more, nothing less. :)
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

	217. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Michael Shigorin (ok) on 26-Июн-11, 20:13
	> а я не про это говорил. я хотел узнать, что значит «годно > для продакшена». О-оо.  Ну например, "жрёт ресурсы пачками, зато как-то принимает нагрузку".  Или вот "подпёрто monit".  И вообще подлежит административному решению проблем, включая технические. По-хорошему -- это то, что достаточно* обкатано в опытной/preprod-эксплуатации и по чему хотя бы известны грабли, нюансы и пути отступления. *depends
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

	225. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??) on 27-Июн-11, 05:07
	> *depends вот именно. потому вопрос «оно уже готово для продакшена» имеет смысл только если уточнять, что именно собираются делать, в каких объёмах и прочие необходимые условия. а просто для продакшена в вакууме… да, готово. ещё с пре-альфа-версии было готово. потому что я так считаю, и всё тут.
	Ответить | Правка | ^ к родителю #217 | Наверх | Cообщить модератору

	233. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от ананим on 27-Июн-11, 08:21
	вообще продакшн как и ынтырпрайз - слова сильно специфические. Из разряда что кто-то предоставляет коммерческую поддержку. При этом факт наложения сотни патчей п заведения сотни запросов на поддержку никак (и никогда) не регламентировался.
	Ответить | Правка | ^ к родителю #225 | Наверх | Cообщить модератору

	41. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от iZEN (ok) on 23-Июн-11, 16:28
	> Суровые парни. Этак скоро маны будут прямо в сорцы копипастить :) JavaDoc видел? Это оно самое. ;)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	187. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Elhana (ok) on 24-Июн-11, 16:31
	Зато там не будет ситуаций, когда вначале приходит патч в ядро "вот эта хрень с виду не нужна - выпилил", а потом его откатывают потому что оказалось нужно.   Когда все не очевидное откомментировано, то таких проблем будет явно меньше.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+2 +/–
Сообщение от Битазавр on 23-Июн-11, 12:33
так и правельно делают, чем лучше исходники снабжены коментами, тем легче искать нужное место и легче понять алгоритмы
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–16 +/–
	Сообщение от пельмешка on 23-Июн-11, 13:58
	Если есть необходимость комментировать код, то значит этот код плохо написан и его надо переделывать, пока не отпадёт необходимость в комментариях.   Тоже самое и отладчиков касается. Необходимость в их использовании говорит о запутанном коде.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	13. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от Зилибоба (ok) on 23-Июн-11, 14:09
	Сам, то писал хоть раз? =) Суровый челябинский кодер. Если код не документирован, то в первую очередь можно сказать о том, что писатель плевал на других и пишет для себя. Ибо он уверен в том что может написать 100500 строк кода так красиво и лаконично что разобраться не составит и труда. Да - конечно. когда в код чуть сложнее "здравствуй мир" в нем необходимы каменты, иначе ты потратишь много времени на ненужные разборки, типа: "а что это за цикл и нафиг он тут нужен"... А так конечно автор прав. Торвальдс мудак и коментил ядро зазря, или кодер плохой... одно из двух...
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	20. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от пельмешка on 23-Июн-11, 14:33
	Не челябинский кодер, а архуский (Дания). Это мнение про комментарии принадлежит некоему Б.Страуструпу.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	31. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от fr0ster (ok) on 23-Июн-11, 15:28
	Цитата так же точна, как напев Желтой Субмарины Абрамом по телефону(С) Что собственно Страустрап по поводу комментов пишет. http://lib.ru/CPPHB/cpptut.txt "Можно рекомендовать такой стиль введения комментариев в программу:      [1] начинать с комментария каждый файл программы: указать в          общих чертах, что в ней определяется, дать ссылки на          справочные руководства, общие идеи по сопровождению          программы и т.д.;      [2] снабжать комментарием каждое определение класса или шаблона          типа;      [3] комментировать каждую нетривиальную функцию, указав: ее          назначение, используемый алгоритм (если только он неочевиден)          и, возможно, предположения об окружении, в котором работает          функция;      [4] комментировать определение каждой глобальной переменной;      [5] давать некоторое число комментариев в тех местах, где          алгоритм неочевиден или непереносим;      [6] больше практически ничего." Кстати говоря Бьярни не ввел бы вообще комментарии в С++ если бы считал их ненужными. Ну и избыточные комментарии это совершенно другое дело, но против них высказывались многие и это никак не значит "код плохо написан и его надо переделывать, пока не отпадёт необходимость в комментариях"
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	33. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Michael Shigorin (ok) on 23-Июн-11, 15:30
	> Это мнение про комментарии принадлежит некоему Б.Страуструпу. Ну и шут с ним и его великом -- если "гура" до седины в бороде дожил, а не осознал, что реализация не всегда прозрачно отражает намерение, и смущает молодняк. И если комментировать реализацию программисту, а не кодеру, обычно действительно смысла мало (в основном интерфейсы и заковыристые места) -- то задумку бывает очень даже полезно.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	34. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от fr0ster (ok) on 23-Июн-11, 15:32
	>> Это мнение про комментарии принадлежит некоему Б.Страуструпу. > Ну и шут с ним и его великом -- если "гура" до > седины в бороде дожил, а не осознал, что реализация не всегда > прозрачно отражает намерение, и смущает молодняк. Ой, вот таки не надо сразу гуру дураком делать. :) Сначала посмотрите насколько точна "цытата" оппонента. Страуструп таки знал, что комменты нужны. Непожлобился даже на два вида комментов.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	36. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Michael Shigorin (ok) on 23-Июн-11, 15:35
	>> если > Ой, вот таки не надо сразу гуру дураком делать. :) if() :) (а с выражениями действительно надо осторожней -- мало ли кто как поймёт...)
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	69. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от ананим on 23-Июн-11, 17:48
	лично я даже и не думал, что выссказывание Страуструпа о необходимости писать код просто настолько, насколько это вообще можно, некоторые воспримут как войну с комментариями. ату его! Вон там goto! быдлокодер-детектед! :D и хрен же убедишь, что в этом куске кода готу убрал кучу иф/элсе и тд...
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	107. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??) on 23-Июн-11, 23:08
	а вот тут начинает не зватать терминов. комментировать перед функцией — вход, выход, какие подводные камни и применимость — это одно. а комментировать потом код функции — это другое. если первое — оправдано и полезно, то второе — признак быдлокода.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	135. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от ананим on 24-Июн-11, 03:45
	>то второе — признак быдлокода. от быдло-кодера слышу! Этож писец! Теперь что и в структурах не писать какие значения могут принимать члены? И граничные условия? И если реализация не полная, тоже ссылки не давать? это чё, вот это head -50 /usr/src/linux-3.0-rc4/include/linux/superhyway.h struct superhyway_vcr_info {     u8    perr_flags;    /* P-port Error flags */     u8    merr_flags;    /* Module Error flags */     u16    mod_vers;    /* Module Version */     u16    mod_id;        /* Module ID */     u8    bot_mb;        /* Bottom Memory block */     u8    top_mb;        /* Top Memory block */ }; уже быдло код? А по мне, так это пример хорошо документированного кода. Или этот /usr/src/linux-3.0-rc4/drivers/parport/parport_serial.c static int __devinit netmos_parallel_init(struct pci_dev *dev, struct parport_pc_pci *par, int autoirq, int autodma) {     /* the rule described below doesn't hold for this device */     if (dev->device == PCI_DEVICE_ID_NETMOS_9835 &&             dev->subsystem_vendor == PCI_VENDOR_ID_IBM &&             dev->subsystem_device == 0x0299)         return -ENODEV;     /*      * Netmos uses the subdevice ID to indicate the number of parallel      * and serial ports.  The form is 0x00PS, where <P> is the number of      * parallel ports and <S> is the number of serial ports.      */     par->numports = (dev->subsystem_device & 0xf0) >> 4; и мне наплевать что об этом думают местные гении. Этот код отлично читается и без документации.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	21. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 23-Июн-11, 14:41
	В идеальном случае код должен быть написан так чтобы коментов не требовалось. В реальном, конечно коменты нужны. Но когда их 40% от кода - это уже оверкилл и напрашивается вывод что кто-то перепутал сорец с документацией :)
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	25. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 23-Июн-11, 15:15
	Просто Вы не видели реализацию сложных алгоритмов или структур данных.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	28. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 23-Июн-11, 15:22
	> Просто Вы не видели реализацию сложных алгоритмов или структур данных. Почему же, видел. Просто если хочется что-то именно фундаментально задокументировать - зачем это делать прямо в сорце а не в файлике с документацией?
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	32. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+2 +/–
	Сообщение от fr0ster (ok) on 23-Июн-11, 15:30
	>> Просто Вы не видели реализацию сложных алгоритмов или структур данных. > Почему же, видел. Просто если хочется что-то именно фундаментально задокументировать - > зачем это делать прямо в сорце а не в файлике с > документацией? Затем, что в какой то момент вы рискуете вместо пояснения темных мест реализации алгоритма встретить запись типа "Подробности смотри в тетрадке у Чжаня".
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	80. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 23-Июн-11, 18:28
	> Затем, что в какой то момент вы рискуете вместо пояснения темных мест > реализации алгоритма встретить запись типа "Подробности смотри в тетрадке у Чжаня". Если код пишут товарисчи с таким подходом - им лучше всего вообще не пользоваться ни в коем случае. Так, во избежание. Какими вы только пинками не стройте дураков в стойло, умнее они от пинков не становятся.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	91. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от fr0ster (ok) on 23-Июн-11, 20:49
	>> Затем, что в какой то момент вы рискуете вместо пояснения темных мест >> реализации алгоритма встретить запись типа "Подробности смотри в тетрадке у Чжаня". > Если код пишут товарисчи с таким подходом - им лучше всего вообще > не пользоваться ни в коем случае. Так, во избежание. Какими вы > только пинками не стройте дураков в стойло, умнее они от пинков > не становятся. Лучше то лучше, но иногда выбор небогат. Здесь Родос, здесь и прыгай :)
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	129. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 24-Июн-11, 01:32
	> Лучше то лучше, но иногда выбор небогат. Здесь Родос, здесь и прыгай :) Ну тогда прыгайте, чо. Только так и убиться можно. Умные люди обычно стараются прыгать так чтобы не убиться. А дураки попадают на darwinawards, остальным в назидание...
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	181. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от fr0ster (??) on 24-Июн-11, 13:36
	Вот умные люди и комментируют свой код. Буквально каждый чих. Что бы потом не вспоминать почему в этом мести код такой, а не эдакий.
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	182. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??) on 24-Июн-11, 13:41
	> Вот умные люди и комментируют свой код. > Буквально каждый чих. > Что бы потом не вспоминать почему в этом мести код такой, а > не эдакий. если это надо специально вспоминать, то это называется «хак». хаки, конечно, нужны — но лучше их изолировать куда-нибудь в обёртки и потом трогать поменьше.
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	184. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от fr0ster (??) on 24-Июн-11, 15:04
	Это не хак, это требования контролирующих органов. Ну вот положено считать так, а не эдак. В теме только консультант ставящий задачу, ибо госорганы чуть ли не каждый квартал придумывают новые требования к отчетности. Ну и через полгода не вспомнить, почему округление сделано таким диким образом. А всего лишь, чтоб по алгоритму от ПФР было.
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	185. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??) on 24-Июн-11, 15:12
	> Это не хак, это требования контролирующих органов. Ну вот положено считать так, > а не эдак. В теме только консультант ставящий задачу, ибо госорганы > чуть ли не каждый квартал придумывают новые требования к отчетности. Ну > и через полгода не вспомнить, почему округление сделано таким диким образом. > А всего лишь, чтоб по алгоритму от ПФР было. по-моему, ты только что описал грязный хак.
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

	39. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+2 +/–
	Сообщение от segoon (ok) on 23-Июн-11, 16:23
	Чтобы не было рассинхронизации документации и кода.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	109. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–4 +/–
	Сообщение от anonymous (??) on 23-Июн-11, 23:16
	> Чтобы не было рассинхронизации документации и кода. ты риальне веришь, что при наличии этого в одном файле вероятность десинка меньше? O_O
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

3. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
Сообщение от mealstrom on 23-Июн-11, 12:40
по исходникам, хорошо и грамотно документированым, как раз и делают документацию -- немного подправить ошибки, удалить маты. Это намного удобнее нежели писать документацию с нуля, и спрашивать каждый раз -- "А что это за функция такая, и наф это вообще нужно."
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
Сообщение от Дмитрий (??) on 23-Июн-11, 12:50
А ширину строк учли, интересно? :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним123321 (ok) on 23-Июн-11, 13:42
	в таком случае -- вообще лучше сравнивать количество токенов (слов и разделяющих-знаков)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

11. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
Сообщение от crypt (??) on 23-Июн-11, 14:07
> В коде XFS выявлено 4806 дублирующихся строк в 561 блоках в 55 файлах. В ext4+jbd2 найдено 917 >дубликатов, затрагивающих 116 блоков в 23 файлах. В Btrfs присутствует 2252 дубликатов в 272 блоках в 31 >файле. Имхо, это плохо говорит о ядре. Код не реюзается, а содержит много дубликатов.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	15. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Зилибоба (ok) on 23-Июн-11, 14:10
	>> В коде XFS выявлено 4806 дублирующихся строк в 561 блоках в 55 файлах. В ext4+jbd2 найдено 917 >дубликатов, затрагивающих 116 блоков в 23 файлах. В Btrfs присутствует 2252 дубликатов в 272 блоках в 31 >файле. > Имхо, это плохо говорит о ядре. Код не реюзается, а содержит много > дубликатов. Это говорит о том, что еще оптимизировать и оптимизировать. Тоесть - графики могут на 50 тыс. не сойтись =)
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	30. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–2 +/–
	Сообщение от Аноним (??) on 23-Июн-11, 15:26
	> Имхо, это плохо говорит о ядре. Код не реюзается, а содержит много > дубликатов. Большой вопрос станет ли эффективнее если каждую строку выносить в функцию и потом ее реюзать - накладные расходы на вызов функции могут скомпенсировать такой реюз кода с запасом. А потом фороникс напишет что ядро 3.0 сливает 2.6?! Спасибо, не надо нам таких хороших разговоров.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	37. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от kibab on 23-Июн-11, 15:50
	Откройте для себя inline-функции.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	68. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 23-Июн-11, 17:46
	> Откройте для себя inline-функции. Да. Давайте сделаем каждую строку программы отдельной инлайн-функцией. Извращаться - так по полной! :)
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	117. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+2 +/–
	Сообщение от pavlinux (ok) on 24-Июн-11, 00:23
	const static inline volatile unsigned char* __attribute__((always_inline)) World(void) {      register volatile const char * const str = "Hello World!\n";      return str;   } const static inline size_t __attribute__((always_inline)) Size(const volatile unsigned char * restrict str) {          return (const volatile size_t)strlen((const char *)str);   } const static void inline __attribute__((always_inline)) Hello(const volatile unsigned char * restrict str) {          write(1, (const void *)str, Size(str)); } extern signed int main(void) {          Hello(World());          return 0; } Главное это не заблудиться между restict, const * const и volatile :)
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	132. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+2 +/–
	Сообщение от Аноним (??) on 24-Июн-11, 01:45
	> restict, Ты уже ^^^^^ заблудился :P.
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	45. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 23-Июн-11, 16:54
	Угу. В одном коде везде написано «for (i = 0; i < sz; i++)», а в другом то «sz», то «size», то «count». А потом приходит особо умный дядя и заявляет, что в первом отрывке дублируется строк кода больше. Не говоря о том, что иногда код действительно лучше продублировать — лишь бы связь с «коллегами» не терялась. Special for кто слышал звон про inline-функции и макросы препроцессора: это тоже не всегда удобно, например, когда используется много переменных, или когда семантически код идентичен, но конкретная реализация завязана на разрядность регистров, и т.п.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

12. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
Сообщение от zamir (??) on 23-Июн-11, 14:08
Пути графиков сойдутся на 50тыс. срок :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+5 +/–
Сообщение от ImPressed (ok) on 23-Июн-11, 14:28
Статья из серии "Занимательная фалометрия для Чайников или как создать срач на ровном месте" для участников специальных олимпиад. Вот мне бы без разницы где сколько строк и сколько комментариев в исходниках, лучше бы стабильность, фичастость и прочие нужные вещи сравнили, т.к числом строк и комментариев фичастость со стабильность не измеряется ( гляньте для примера в индусские сорцы, там строк столько, что закачаешься=), и код пестрит утверждениями вида switch(a) { case true:...break; case false:...break; default:...break; } и им подобными или к китайцам в код гляньте, там вообще жесть несусветная творится).
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	26. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 23-Июн-11, 15:19
	> Статья из серии "Занимательная фалометрия для Чайников или как создать срач на > ровном месте" для участников специальных олимпиад. > Вот мне бы без разницы где сколько строк и сколько комментариев в > исходниках, лучше бы стабильность, фичастость и прочие нужные вещи сравнили, т.к > числом строк и комментариев фичастость со стабильность не измеряется Чем больше код, тем больше ошибок. Чем меньше комментариев, тем сложнее его поддерживать и больше ошибок при рефакторинге.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	48. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от fr0ster (ok) on 23-Июн-11, 17:04
	> Чем больше код, тем больше ошибок. > Чем меньше комментариев, тем сложнее его поддерживать и больше ошибок при рефакторинге. С другой стороны и при минимуме кода бывают интересные ошибки. Думали код временный, а вышло как всегда, надо поддерживать его и модифицировать до морковкина заговенья. Да и большое количество кода не гарантирует беспроблемность рефакторинга.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	169. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 24-Июн-11, 12:41
	> С другой стороны и при минимуме кода бывают интересные ошибки. Бываают, но мистер D.J. Berstein делом доказал что это отличный способ минимизации ошибок. Его программы реально непрошибаемы.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	49. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+2 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 23-Июн-11, 17:07
	> Чем больше код, тем больше ошибок. > Чем меньше комментариев, тем сложнее его поддерживать и больше ошибок при рефакторинге. Чем меньше _полезных_ комментариев. И чем больше бесполезных. Индусское комментирование в стиле: /* * prod_average_price - функция для формирования средней цены. * * Входные параметры: * struct elm *a - указатель на массив данных * int c - количество элементов в массиве * * Возвращаемое значение: * double - средняя цена продуктов в массиве. */ double prod_average_price(struct elm *a, int c) {         int i;    // счётчик         double s;    // сумма цен продуктов        for (i = 0, s = 0; i < c; i++)                // прибавляем цену каждого продукта к значению s                s += a[i].price;         // разделим на количество продуктов         return (s / c); } — тоже маразм, который лишь отвлекает и заставляет тратить силы на его поддержание; бюрократия без необходимости.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	53. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от fr0ster (ok) on 23-Июн-11, 17:18
	Маразм, но иногда алгоритм не так прозрачен, как кажется (возьмите алгоритм округления начисленного налога при сдаче отчетности в ПФР реализованный в чекере от БухСофта и по которому ПФР проверяет принимаемую отчетность), иногда имена переменных определены не разработчиком данного кода (В саповских отчетах приходится использовать имена придуманные индусами из вальдорфа, далеко не всегда по ним можно сказать для чего объект назначен, а абапера сведущего в данном модуле может и не быть под рукой). Вот и получается, без подобных комментариев ну никак. И главное слезть с кактуса нельзя, кушать надо всем, надо семью одеть накормить :)
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	55. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 23-Июн-11, 17:21
	> Маразм, но иногда алгоритм не так прозрачен, как кажется (возьмите алгоритм округления > начисленного налога при сдаче отчетности в ПФР реализованный в чекере от > БухСофта и по которому ПФР проверяет принимаемую отчетность), иногда имена переменных > определены не разработчиком данного кода (В саповских отчетах приходится использовать > имена придуманные индусами из вальдорфа, далеко не всегда по ним можно > сказать для чего объект назначен, а абапера сведущего в данном модуле > может и не быть под рукой). Вот и получается, без подобных > комментариев ну никак. И главное слезть с кактуса нельзя, кушать надо > всем, надо семью одеть накормить :) Я и не спорю, что иногда это, к сожалению, нужно. Речь была как раз о том, что в тривиальных, очевидных ситуациях подобные комментарии — зло. Сорцы индийских CMS-ок видели когда-нибудь? Это ж зачастую полный атас, 90% комментариев описывают только сами операции, но не к чему это приводит, или что затрагивает — а именно эта информация в комментариях востребована больше всего.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	60. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от fr0ster (ok) on 23-Июн-11, 17:29
	> Я и не спорю, что иногда это, к сожалению, нужно. Речь была > как раз о том, что в тривиальных, очевидных ситуациях подобные комментарии Жаль только тривиальные случаи это вовремя не обнаруженные необычности. > — зло. Сорцы индийских CMS-ок видели когда-нибудь? Это ж зачастую полный > атас, 90% комментариев описывают только сами операции, но не к чему > это приводит, или что затрагивает — а именно эта информация в > комментариях востребована больше всего. Индусский код видел. Не в ЦМС, но ЕРП. Насчет атаса согласен. И проблема не столько в комментах, сколько в прочем коде.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	64. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 23-Июн-11, 17:34
	>> Я и не спорю, что иногда это, к сожалению, нужно. Речь была >> как раз о том, что в тривиальных, очевидных ситуациях подобные комментарии > Жаль только тривиальные случаи это вовремя не обнаруженные необычности. Дык на то голова программисту и дана, чтобы отличать одно от другого... Чем проще код, чем он предсказуемее, тем легче его поддерживать. :) >> — зло. Сорцы индийских CMS-ок видели когда-нибудь? Это ж зачастую полный >> атас, 90% комментариев описывают только сами операции, но не к чему >> это приводит, или что затрагивает — а именно эта информация в >> комментариях востребована больше всего. > Индусский код видел. Не в ЦМС, но ЕРП. Насчет атаса согласен. И > проблема не столько в комментах, сколько в прочем коде. Угу. В коде ДНК...
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	66. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от fr0ster (ok) on 23-Июн-11, 17:42
	>> Жаль только тривиальные случаи это вовремя не обнаруженные необычности. > Дык на то голова программисту и дана, чтобы отличать одно от другого... > Чем проще код, чем он предсказуемее, тем легче его поддерживать. :) Если архитектура запутанна, то медицина бессильна. Весь код не может быть ясным на 100%, если архитектура "прости господи", "туши свет, кидай гранату" и "святых выноси". >> Индусский код видел. Не в ЦМС, но ЕРП. Насчет атаса согласен. И >> проблема не столько в комментах, сколько в прочем коде. > Угу. В коде ДНК... Не столько кодеров, сколько архитекторов и администраторов. И руководства. Это если не брать кодинг4фан. :)
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	97. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 23-Июн-11, 21:23
	>>> Жаль только тривиальные случаи это вовремя не обнаруженные необычности. >> Дык на то голова программисту и дана, чтобы отличать одно от другого... >> Чем проще код, чем он предсказуемее, тем легче его поддерживать. :) > Если архитектура запутанна, то медицина бессильна. Весь код не может быть ясным > на 100%, если архитектура "прости господи", "туши свет, кидай гранату" и > "святых выноси". Дык вы ж сами и привели примеры, когда внешние обстоятельства заставляют городить что-то сложное. А в особо тяжёлых случаях, когда, например, делается реверс-инжиниринг таинственной железки или софтины, код вообще трогать стрёмно: от безобидной смены порядка операций чтения в ходе рефакторинга Тот-Кого-Нельзя-Вызывать может просто перестать работать... >>> Индусский код видел. Не в ЦМС, но ЕРП. Насчет атаса согласен. И >>> проблема не столько в комментах, сколько в прочем коде. >> Угу. В коде ДНК... > Не столько кодеров, сколько архитекторов и администраторов. И руководства. > Это если не брать кодинг4фан. :) Угу. Рыба с головы гниёт.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

23. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
Сообщение от Sokoloff on 23-Июн-11, 14:51
Как можно сравнивать прирост кода в старой(2001) XFS, с ее устоявшейся базой. И Btrfs, которую еще только пилят. Это же для любого проекта так, изменения в коде между 0.1 и 0.2 огромны по сравнению с чем нибудь вроде 8.1 и 8.2.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	29. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+4 +/–
	Сообщение от Аноним (??) on 23-Июн-11, 15:23
	> Как можно сравнивать прирост кода в старой(2001) XFS, с ее устоявшейся базой. Форониксу - можно :)
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

38. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
Сообщение от fresco (ok) on 23-Июн-11, 15:59
крайний раз копался в коде btrfs с год назад, откомментирован он действительно очень скупо, не сравнить даже с reiserfs, не то, что с XFS. сейчас, говорят, стало лучше.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	70. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 23-Июн-11, 17:49
	> крайний раз копался в коде btrfs с год назад, откомментирован он действительно очень скупо, Есть такой грешок за ними, факт. С другой стороны когда 40% исходника это коменты - тоже как-то перебор уже. Все хорошо в меру.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	100. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от fresco (ok) on 23-Июн-11, 21:48
	> Есть такой грешок за ними, факт. С другой стороны когда 40% исходника > это коменты - тоже как-то перебор уже. Все хорошо в меру. много -- не мало, процентов 35, по опыту, в самый раз.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

40. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
Сообщение от iZEN (ok) on 23-Июн-11, 16:26
> В коде XFS выявлено 4806 дублирующихся строк в 561 блоках в 55 файлах. В ext4+jbd2 найдено 917 дубликатов, затрагивающих 116 блоков в 23 файлах. В Btrfs присутствует 2252 дубликатов в 272 блоках в 31 файле. Дедупликация ZFS уменьшит занимаемое ими место. :))
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	51. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 23-Июн-11, 17:12
	>> В коде XFS выявлено 4806 дублирующихся строк в 561 блоках в 55 файлах. В ext4+jbd2 найдено 917 дубликатов, затрагивающих 116 блоков в 23 файлах. В Btrfs присутствует 2252 дубликатов в 272 блоках в 31 файле. > Дедупликация ZFS уменьшит занимаемое ими место. :)) Неа. Дедупликация ZFS действует только на блоки. Очевидно, даже несколько идущих подряд строк будут занимать места гораздо меньше, чем размер одного блока. Кстати, в btrfs тоже есть дедупликация, но я что-то не вижу глупых шуток на эту тему.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	71. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–1 +/–
	Сообщение от ананим on 23-Июн-11, 17:53
	это всё потому, что есть куча народу "гордящегося_неимоверно" новой цацкой, а не своими познаниями.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	146. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Anon Y Mous on 24-Июн-11, 09:15
	> Кстати, в btrfs тоже есть дедупликация, но я что-то не вижу глупых  шуток на эту тему. И давно она там есть? Какой командой делается? Ах, в виде патчей..
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	72. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–2 +/–
	Сообщение от Аноним (??) on 23-Июн-11, 17:54
	> Дедупликация ZFS уменьшит занимаемое ими место. :)) Сапожник! Дедупликация ZFS не оперирует строками, она дисковыми блоками оперирует. Если бы твой дохлый мозг еще и понимал как работает дедупликация, ты бы осознал что вероятность того что строки будут дедуплицированы - в районе нуля.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	87. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–3 +/–
	Сообщение от iZEN (ok) on 23-Июн-11, 19:58
	>> Дедупликация ZFS уменьшит занимаемое ими место. :)) > Сапожник! Дедупликация ZFS не оперирует строками, она дисковыми блоками оперирует. Если > бы твой дохлый мозг еще и понимал как работает дедупликация, ты > бы осознал что вероятность того что строки будут дедуплицированы - в > районе нуля. Что же с вами случилось, люуууудиии? Сарказм уже воспринимают как "личный наезд" и хохочущий смайлик даже не помогает.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	94. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от crypt (??) on 23-Июн-11, 21:10
	Уж извини, не слежу за темой, но видать, заслужил ты имидж среди местного народа.)
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	95. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от crypt (??) on 23-Июн-11, 21:14
	Да, кстати, был же этот... товарищь от M$ со звучной фамилией. Тот был еще провокатор и его еще больше норовили пнуть.:) (это вобще уже можно считать национальной фичей)
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	111. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от anonymous (??) on 23-Июн-11, 23:47
	> Уж извини, не слежу за темой, но видать, заслужил ты имидж среди > местного народа.) не только среди местного.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	172. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от Аноним (??) on 24-Июн-11, 12:46
	> не только среди местного. iZEN умудряется сливать сразу на многих ресурсах, будучи наглядной иллюстрацией по теме пионерии и жабистов :)
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	101. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+2 +/–
	Сообщение от fresco (ok) on 23-Июн-11, 21:51
	> Что же с вами случилось, люуууудиии? Сарказм уже воспринимают как "личный наезд" > и хохочущий смайлик даже не помогает. пора тэг <irony> вводить, а то так понимать перестали.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	160. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от йопт (??) on 24-Июн-11, 11:12
	> пора тэг <irony> вводить пора только без поиска от витеньки
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	173. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 24-Июн-11, 12:47
	> пора тэг <irony> вводить, а то так понимать перестали. iZEN слишком толстый, ему этот тег не засчитают ;)
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	104. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от gegMOPO4 (ok) on 23-Июн-11, 22:52
	Инфляция.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

43. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–1 +/–
Сообщение от IamthinkingaboutBTRFS on 23-Июн-11, 16:41
Кто-нибудь в жизни её использует? А то уж очень хочется неограниченного количества снапшотов на уровне ФС. В продакшене уже хочется, прям не могу. Если не btrfs, то какие ещё есть альтернативы под GNU/Linux?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	44. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от iZEN (ok) on 23-Июн-11, 16:47
	http://ru.wikipedia.org/wiki/NILFS
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	52. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от Аноним (??) on 23-Июн-11, 17:13
	> Если не btrfs, то какие ещё есть альтернативы под GNU/Linux? ZFS уже давно портировали на линакс, между прочим.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	57. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Frank (ok) on 23-Июн-11, 17:23
	Использую на нетбуке с 64 GB SSD с выхода убунты 10.10 по текущий момент. Несколько зимних месяцев бук работал в режиме зависания раз в день. С апгрейдом на убунту 11.04 появилась btrfsck, а режим работы сменился на зависание раз в неделю :) За всё время работы из замеченных проблем было только повреждение файла в случае его записи непосредственно перед зависанием. Если сейчас сделать sudo btrfsck /dev/sda2, то получаю 175 строк вида "Extent back ref already exists for 152821760 parent 0 root 7" или "parent transid verify failed on 206823424 wanted 465419 found 465417" или "leaf parent key incorrect 43388928", но всё работает как обычно - возможно, нужно отмонтировать ФС перед проверкой, я не в курсе :) P.S. вы не подумайте - зависания никак не связаны с btrfs, это косяки поддержки конкретной платформы. На текущий момент все подвисания только от корявостей в сервере xorg (точнее даже в драйвере intel i915).
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	76. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+2 +/–
	Сообщение от Алексей Волков on 23-Июн-11, 18:10
	Пробовал btrfs начиная с Ubuntu 10.10 с последующим апдейтом до 11.04, причем основной упор делал на отказоустойчивость за счет зеркалирования как данных так и метаданных. Вышло все очень плохо. Во первых после обновления до 11.04 появилась фаза fsck.btrfs которая работала при каждом ребуте минуты три и завершалась падением в корку, а во вторых по отдельности винты отказались грузиться и читаться из бод других отдельно стоящих OS с поддержкой btrfs (хотя по началу такой фокус проходил) по этому смысл зеркала получился никакой. Сейчас все снес и перешел на чистый debian + сборку linux native zfs. Такой вариант несмотря на его бету (я о zfs) мне нравиться гораздо больше, зеркало реально работает и отказ одного винта реально не заметен.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	82. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–2 +/–
	Сообщение от Аноним (??) on 23-Июн-11, 18:40
	Только если что - у zfs вообще fsck нет, даже в планах ;). А у btrfs он пока попросту бесполезный т.к. сырой еще напрочь - его только сделали.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	86. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–1 +/–
	Сообщение от iZEN (ok) on 23-Июн-11, 19:08
	> Только если что - у zfs вообще fsck нет, даже в планах ;). zpool scrub poolname — рассчитывает все контрольные суммы файлов и метаданных и сверяет их с теми, что есть, выводит список запорченных файлов, если они есть. Выполняется в фоне, при перезапусках продолжает работу с того места ФС, где закончила в последний раз. Правда, не похоже на унылый fsck традиционных ФС? ;)
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	89. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 23-Июн-11, 20:37
	> zpool scrub poolname — рассчитывает все контрольные суммы файлов и метаданных и > сверяет их с теми, что есть, выводит список запорченных файлов, если > они есть. Выполняется в фоне, при перезапусках продолжает работу с того > места ФС, где закончила в последний раз. > Правда, не похоже на унылый fsck традиционных ФС? ;) Все это замечательно, но убитые метаданные не восстановит. Так что действительно, на fsck не тянет.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	113. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–1 +/–
	Сообщение от Мяут (ok) on 23-Июн-11, 23:49
	Там оно и не нужно. CoW, контрольные суммы и дублирование метаданных решают, а баги системы и fsck не починит. Кстати, сравнение кодовой базы UFS+SVM и ZFS: -------------------------------------------------   UFS: kernel= 46806   user= 40147   total= 86953   SVM: kernel= 75917   user=161984   total=237901 TOTAL: kernel=122723   user=202131   total=324854 -------------------------------------------------   ZFS: kernel= 50239   user= 21073   total= 71312 ------------------------------------------------- отсюда: http://blogs.oracle.com/eschrock/entry/ufs_svm_vs_zfs_code
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	114. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??) on 23-Июн-11, 23:56
	> Там оно и не нужно. адептам свойственно говорить, что то, чего у них в технологии нет, на самом деле не нужно. как только кто-то это «ненужное» дописывает — оно сразу становится нужным, полезным и уберфичей.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	115. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Мяут (ok) on 24-Июн-11, 00:06
	ZFS изначально проектировался, как надежная ФС, для которой бы не требовался fsck. Понятное дело, что это умозаключение всего лишь теоретическое.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	116. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??) on 24-Июн-11, 00:09
	дык. можно подумать, что та же винда изначально проектировалась как система, которая будет падать. лучше иметь ненужную тулзу, чем не иметь нужной.
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	118. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Мяут (ok) on 24-Июн-11, 00:47
	Ну есть zdb если на то уж пошло. А все фичи fsck типа определения сбойной ФС в ZFS делаются на-лету, так что утверждать, что у ZFS нет аналога fsck я бы не стал :-) Например взять выделение блока. В ZFS используются т.н. space maps являющиеся по сути логами транзакций, равно как в каком-нить ext3 fsck будет искать блоки-потеряшки, здесь в случае сбоя ZFS откатится на предыдущее состояние лога. Во время же выделения мы проигрываем лог.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	206. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 25-Июн-11, 20:31
	> Ну есть zdb если на то уж пошло. Он может проверить все структуры на валидность и починить все что невалидно или хотя-бы нейтрализовать, чтобы пул можно было смонтировать и выколупать то что уцелело? > А все фичи fsck типа определения сбойной ФС в ZFS делаются на-лету, > так что утверждать, что у ZFS нет аналога fsck я бы не стал :-) Сбой фс нынче обнаруживает любой приличный драйвер. Но проблема в том что чинить их он не умеет - не его епархия.. > блоки-потеряшки, здесь в случае сбоя ZFS откатится на предыдущее состояние лога. А теперь представьте себе что цепочка логов порушилась где-то в середине. Или метаданные описываюшие оную. > Во время же выделения мы проигрываем лог. Вы рассматриваете только простые сбои, которые должна обработать обычная логика журналирования. Тогда как fsck обычно пользуются лишь тогда, когда эта логика не смогла отработать как надо. Когда мы видим что дело дрянь и основной парашют не сработал - нервно сглатываем и дергаем запасной. А вы в вашем праве превращаться в лепешку, если вам так удобнее.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	207. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от iZEN (ok) on 25-Июн-11, 20:58
	>> Ну есть zdb если на то уж пошло. > Он может проверить все структуры на валидность и починить все что невалидно > или хотя-бы нейтрализовать, чтобы пул можно было смонтировать и выколупать то > что уцелело? http://www.freebsd.org/cgi/man.cgi?query=zdb >> блоки-потеряшки, здесь в случае сбоя ZFS откатится на предыдущее состояние лога. > А теперь представьте себе что цепочка логов порушилась где-то в середине. Или > метаданные описываюшие оную. То только эта цепочка и будет недоступна. >> Во время же выделения мы проигрываем лог. > Вы рассматриваете только простые сбои, которые должна обработать обычная логика журналирования. > Тогда как fsck обычно пользуются лишь тогда, когда эта логика не > смогла отработать как надо. В самом деле? https://osu.redhat.com/content/courses-ru/rha130-50-2-ru/tag... --- Использование команды fsck Команда fsck обычно вызывается с именем раздела, который нужно проверить, в качестве единственного параметра. Если команда fsck найдет ошибку, которую она сможет исправить без риска потери данных, она исправит ее. Если есть риск потери данных, команда fsck приостановится и выдаст сообщение с вопросом, должна ли она исправлять ошибку. Для администраторов, которые не обладают подробными знаниями в области внутренней структуры файловой системы ext2, выбор невелик. По правде говоря, команда fsck часто запускается с ключом -y, который так и говорит: "Не спрашивать, просто делать". --- > Когда мы видим что дело дрянь и основной парашют не сработал - нервно сглатываем и дергаем запасной. А он у вас есть? Бэкапы хотя бы сделали? :)) > А вы в вашем праве превращаться в лепешку, если вам так удобнее. У нас хотя бы мусор из-за бэд-блока на одном носителе можно достоверно обнаружить, а на группе носителей в RAID невозможен в принципе.
	Ответить | Правка | ^ к родителю #206 | Наверх | Cообщить модератору

	221. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Мяут (ok) on 27-Июн-11, 01:39
	> А теперь представьте себе что цепочка логов порушилась где-то в середине. Можно вот рассказать, как это могло получиться, со ссылочками на on-disk format? Есть подозрения что ФС пойдет через Traverse в поисках блоков. Ну или опять же поедет на старую неповрежденную версию лога. > Он может проверить все структуры на валидность и починить все что невалидно или хотя-бы нейтрализовать, чтобы пул можно было смонтировать и выколупать то что уцелело? Валидность структуры - это сущая эвристика. Уж лучше контрольные суммы и транзакционная модель.
	Ответить | Правка | ^ к родителю #206 | Наверх | Cообщить модератору

	147. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Anon Y Mous on 24-Июн-11, 09:19
	>> Там оно и не нужно. > адептам свойственно говорить, что то, чего у них в технологии нет, на > самом деле не нужно. как только кто-то это «ненужное» дописывает — > оно сразу становится нужным, полезным и уберфичей. Да-да.. Сколько было излито желчи по поводу того, что ZFS - комбайн-все-в-одном-и-ни-нужно, а теперь оказывается, что если комбайн-все-в-одном называется btrfs - то он внезапно уже оказывается нужен. Двойные стандарты такие двойные :)
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	195. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 25-Июн-11, 00:26
	Желчь была в основном потому что ZFSники утверждали что оно такое незаменимое.Хотя по факту LVM и рэйды с обычной ФС поверх вполне могут похожее по функционалу изобралить, а удобство администрирования - вопрос вкуса и предпочтений. А btrfs нужен всем по разным причинам. Кому-то потому что CoW означает неразрушающую и быструю запись. Кому-то за эффективные снапшоты. Кому-то за управление томами. А кому-то за просто скорость. Btrfs не ударяет в грязь лицом даже на low end системах, вплоть до эмбеддовки. В отличие от ZFS, которому с его блочным дизайном и жуткой фрагментацией надо минимум несколько Гб оперативки чтобы нормально работать, а не тормозить. И в большинстве бенчей почему-то btrfs уже сто лет назад делал ZFS.
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	148. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Anon Y Mous on 24-Июн-11, 09:23
	> отсюда: http://blogs.oracle.com/eschrock/entry/ufs_svm_vs_zfs_code От 2005 года данные, когда исходники ZFS открыли. Сейчас количество строк кода в ядре - уже под сто тысяч. Но и функциональности прибавилось в сравнении с 2005.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	194. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 25-Июн-11, 00:18
	> Там оно и не нужно. Ага, вот вылезет у вас бэд так что ФС перестанет монтироваться, бэкап фигакс и старый, а вон те файлики - позарез нужно. И будете вы пухнуть, разбирая по ночам навороченные структуры хексэдитором. Вместо того чтобы починиться стандартной утилитой.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	222. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Мяут (ok) on 27-Июн-11, 01:44
	>> Там оно и не нужно. > Ага, вот вылезет у вас бэд так что ФС перестанет монтироваться, бэкап > фигакс и старый, а вон те файлики - позарез нужно. И > будете вы пухнуть, разбирая по ночам навороченные структуры хексэдитором. Вместо того > чтобы починиться стандартной утилитой. Это у вас бэд приводит к немонтируемой ФС, у нас 4 копии метки на VDEV и 3 копии метаданных.
	Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

	120. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от iZEN (ok) on 24-Июн-11, 00:56
	>> zpool scrub poolname — рассчитывает все контрольные суммы файлов и метаданных и >> сверяет их с теми, что есть, выводит список запорченных файлов, если >> они есть. Выполняется в фоне, при перезапусках продолжает работу с того >> места ФС, где закончила в последний раз. > Все это замечательно, но убитые метаданные не восстановит. Так что действительно, на fsck не тянет. А зачем ему что-то восстанавливать? Сама ZFS спроектирована по принципу CoW — если что-то повреждается, то восстанавливается легко и непринуждённо откатом на предыдущее состояние, если ФС видит потерю данных на одной из половины зеркала, то не кричит об этом, а тихо восстанавливает данные по другой половине (то же самое с другими избыточными моделями хранения данных). Если данные не восстановимы в принципе, то пул тупо останавливает свою работу, чтобы предотвратить потерю консистентности метаданных самой файловой системы, а там уж администратор должен сам разобраться в проблеме — fsck на такое не способна, и ни один из линуксовых RAID не может в этом помочь: http://www.linux.org.ru/jump-message.jsp?msgid=3262617&cid=3...
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	198. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 25-Июн-11, 13:27
	> А зачем ему что-то восстанавливать? Сама ZFS спроектирована по принципу CoW — > если что-то повреждается, то восстанавливается легко и непринуждённо откатом на > предыдущее состояние, Малацца, основы CoW зазубрил. Садись, пять. И положи букварь на парту. Только у данного устройства ФС есть проблема: относительно небольшое разрушение метаданных может вызывать очень невкусные последствия. Знаешь что такое "эффект домино"? Ну вот снапшоты - они друг за другом, как костяшки домино. Грохнется что-то в одном? Полетит все что было за ним. Потому что зависит от предшествующего куска. И уж хотя-бы перестроить метаданные в случае опы, например порушеный индекс на основе данных целого индекса - было бы очень кстати, не говоря уж про исправление заведомо некорректных метаданных/проблемных и прочая. > если ФС видит потерю данных на одной из половины зеркала, то не кричит об этом, > а тихо восстанавливает данные по другой половине (то же самое с другими > избыточными моделями хранения данных). При условии если это вообще получилось. Вообще-то, запасной парашют нужно дергать только если основной (стандартная журнальная механика) не сработал. Может быть до тебя это уже дойдет, двоечник? :) > Если данные не восстановимы в принципе, то пул тупо останавливает свою работу, Да. И далее ты или выгребаешь из него хексэдитором нужные файлы или клюешь. Как мило! > чтобы предотвратить потерю консистентности метаданных самой файловой системы, а там уж > администратор должен сам разобраться в проблеме — fsck на такое не способна, Администратору приводить метаданные в консистентное и непротиворечивое состояние "немного" сложнее и дольше чем утилитам. > и ни один из линуксовых RAID не может в этом помочь: А почему RAID должен помогать в починке метаданных ФС? Если ты вдруг не знал, RAID далеко не панацея и справляется далеко не с любыми сценариями разрушений. Кстати, даже лучшая конструкция парашюта очень редко но все-таки может не сработать. Поэтому изобрели запасные парашюты. > http://www.linux.org.ru/jump-message.jsp?msgid=3262617&cid=3... Тебя так прикалывает демонстрировать свою тупость?
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	202. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от iZEN (ok) on 25-Июн-11, 17:44
	>[оверквотинг удален] >> предыдущее состояние, > Малацца, основы CoW зазубрил. Садись, пять. И положи букварь на парту. Только > у данного устройства ФС есть проблема: относительно небольшое разрушение метаданных может > вызывать очень невкусные последствия. Знаешь что такое "эффект домино"? Ну вот > снапшоты - они друг за другом, как костяшки домино. Грохнется что-то > в одном? Полетит все что было за ним. Потому что зависит > от предшествующего куска. И уж хотя-бы перестроить метаданные в случае опы, > например порушеный индекс на основе данных целого индекса - было бы > очень кстати, не говоря уж про исправление заведомо некорректных метаданных/проблемных > и прочая. Матчасть подучи: http://blogs.oracle.com/bonwick/ru/category/ZFS --- Нисходящее восстановление: пул дисковой памяти - это дерево блоков. Чем ближе к корню дерева находится блок, тем значительнее его потеря, так как она означает потерю доступа к во всем потомкам этого блока. Использование метаданных позволяет ZFS осуществлять нисходящее восстановление избыточности. Это значит, что в первую очередь ZFS восстановит убер-блок и метки диска. Затем будет восстановлена избыточность метаданных, общих для всего пула; затем метаданных каждой файловой системы; и так далее вниз по дереву. В ходе этого процесса ZFS следует такому правилу: ибыточность блока не восстанавливается до тех пор, пока не восстановлена избыточность всех его предков. Трудно преувеличить важность этого правила. При прямолинейном копировании всего диска, даже если успешно скопировано 99%, есть неплохой шанс, что один из верхних блоков дерева еще не скопирован. С точки зрения среднего времени восстановления после отказа (MTTR) это значит, что прогресса нет: отказ или ошибка второго диска в этот момент времени все еще будет иметь катастрофические последствия. При нисходящем восстановлении избыточности, копирование каждого следующего блока увеличивает количество данных, которые могут быть обнаружены. В случае сбоя еще одного диска, все данные, избыточность которых была восстановлена до этого момента, останутся доступными. --- >> если ФС видит потерю данных на одной из половины зеркала, то не кричит об этом, >> а тихо восстанавливает данные по другой половине (то же самое с другими >> избыточными моделями хранения данных). > При условии если это вообще получилось. Вообще-то, запасной парашют нужно дергать только > если основной (стандартная журнальная механика) не сработал. Может быть до тебя > это уже дойдет, двоечник? :) Вообще-то, "запасной парашют" в ZFS всегда на готове и он готов для дёрганья в тот момент, когда основной отвалился, а не когда мы уже на земле. --- ZFS использует сквозные контрольные суммы для выявления и исправления неявных нарушений целостности данных. Если диск возвращает некорректные данные в результате случайного сбоя, ZFS определит это и попытается прочитать данные еще раз. Если диск является частью "зеркала" или RAID-Z, ZFS не только определит, но и исправит ошибку: контрольная сумма позволит определить правильную копию, предоставить корректные данные приложению и исправить с их помощью поврежденную копию. --- >> Если данные не восстановимы в принципе, то пул тупо останавливает свою работу, > Да. И далее ты или выгребаешь из него хексэдитором нужные файлы или клюешь. Как мило! Опять двадцать пять. Начинай сначала. >> чтобы предотвратить потерю консистентности метаданных самой файловой системы, а там уж >> администратор должен сам разобраться в проблеме — fsck на такое не способна, > Администратору приводить метаданные в консистентное и непротиворечивое состояние "немного" > сложнее и дольше чем утилитам. Правда что ли? Неужели пробовал восстанавливать RAID из состояния FAULTED, чтобы это говорить? На mdraid это вообще бессмысленно. >> и ни один из линуксовых RAID не может в этом помочь: > А почему RAID должен помогать в починке метаданных ФС? А почему нет, если он интегрирован с ФС? > Если ты вдруг не знал, RAID далеко не панацея и справляется далеко не с любыми сценариями разрушений. Конечно не панацея. Все привыкли к "обыденности", задаваемой "линуксовой братией". :)) > Кстати, даже лучшая конструкция парашюта очень редко но > все-таки может не сработать. Поэтому изобрели запасные парашюты. >> http://www.linux.org.ru/jump-message.jsp?msgid=3262617&cid=3... > Тебя так прикалывает демонстрировать свою тупость? Почему свою? Это ваша тупость, данная вам в ощущениях.
	Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

	208. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 25-Июн-11, 23:05
	> Матчасть подучи: http://blogs.oracle.com/bonwick/ru/category/ZFS Это ты себе? > Нисходящее восстановление: пул дисковой памяти - это дерево блоков. Чем ближе к > корню дерева находится блок, тем значительнее его потеря, Как ты думаешь, к чему относилось про эффект домино? CoW довольно легко повреждается и повреждения даже небольшого участка метаданных или данных могут выбить довольно много всего в результате. Потому что текущий вид данных зависит от предыдущего. > Использование метаданных позволяет ZFS осуществлять нисходящее восстановление избыточности. Тут делается вольное допущение что избыточность есть, что это удалось и что нигде не облажались. В реальной жизни таких гарантий даже страховой полис не даст. [копипаст из букваря поскипан] В общем это, копипастить и дурак может. > Вообще-то, "запасной парашют" в ZFS всегда на готове и он готов для > дёрганья в тот момент, когда основной отвалился, а не когда мы уже на земле. И что является парашютом заменяющим fsck? Те несколько хиленьких опций утилиток, затыкающих несколько специфичных сценариев и плевать хотевших на все остальные? Это не парашют, это бутафория какая-то. В упомянутом букваре допускается что избыточность - была, что перестроение дупов прошло успешно и что валидная копия метаданных вообще была. Но зато ни звука про случай когда их не было. И если в крутых энтерпрайзных многодисковых хранилищах еще можно в некоторых случаях надеяться что это будет не настолько уж и неправдой, для более простых юзкейсов вида "один винч на ноуте, и тот осыпался" это как-то очень неубедительно уже смотрится. Ах, я и забыл - сани делали ФС только для энтерпрайзов. Поэтому такие юзкейсы они не рассматривали и вы для этого используете окаменелый UFS. А вот для btrfs это вполне валидная ситуация. Не просто заранее заложенная, а дефолтная для meego на x86. Негде в ноуте или планшетке многодисковое хранилище распихать. > является частью "зеркала" или RAID-Z, ZFS не только определит, но и > исправит ошибку: контрольная сумма позволит определить правильную копию, Покажи мне как сделать эффективное "зеркало" из одного диска в моем ноуте? Или по твоему мнению я там должен использовать окаменелости типа UFS? Ну увидит ФС - ага, том сыпанулся, бэд чексум. Дальше - что? > Опять двадцать пять. Начинай сначала. Ну так я не виноват что ты тугой и до тебя медленно доходит: вполне возможна ситуация, когда диск был 1, на нем хаотично вылезли бэды например. Это типичный десктопно-ноутбучный юзер. Все что сможет ФС - констатировать bad checksum. А восстановить это - не сможет. И хорошо бы юзеру собрать то что от тома осталось и отрепайрить до моунтабельного состояния, чтобы он не упирался, выколупывая останки файлов хексэдитором. Да, некоторые файлы могут быть испорчены. Хорошо если ФС или fsck их как-то пометит как таковые. Но выцепить то что осталось с тома проще всего когда он примонтирован, копированием. Для этого том должен быть доведен до моунтабельного состояния. Утилитой-чекером. > Правда что ли? Неужели пробовал восстанавливать RAID из состояния FAULTED, чтобы это > говорить? На mdraid это вообще бессмысленно. Пробовал и могу сказать что это та еще лотерея. Более того - иногда RAID может так "восстановить" данные что потом вообще костей не соберешь. Кстати, а расскажи, как мне RAID в ноуте забабахать, если там чисто физически место для 1 HDD и более нишиша? >> А почему RAID должен помогать в починке метаданных ФС? > А почему нет, если он интегрирован с ФС? Да хотя-бы потому что RAIDить может быть и некуда. Ну понятное дело что ZFS не ориентирован на мелкие инсталляции "перец с ноутом", все что они смогут сказать - "сам дурак". А вот btrfs очень даже ориентирован на такое применение. Поэтому там не катит говорить "сам дурак". Там чинить придется, а потребовать пять дисков для рэйда - не катит. > Конечно не панацея. Все привыкли к "обыденности", задаваемой "линуксовой братией". :)) Просто btrfs рассчитан на немного более широкие сценарии, в частности и на ноуты там всякие, где разместить многодисковый рэйд попросту негде. Так что неизбежно придется отколупывать юзверям их диски из весьма неприглядного состояния и скорее всего не имея зеркальной копии всех метаданных. > Почему свою? Это ваша тупость, данная вам в ощущениях. Мои ощущения говорят мне что мой ноут с 1 диском как-то сложно сделать осмысленным RAIDом.
	Ответить | Правка | ^ к родителю #202 | Наверх | Cообщить модератору

	213. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от iZEN (ok) on 26-Июн-11, 00:44
	>> Опять двадцать пять. Начинай сначала. > Ну так я не виноват что ты тугой и до тебя медленно > доходит: вполне возможна ситуация, когда диск был 1, на нем хаотично > вылезли бэды например. Это типичный десктопно-ноутбучный юзер. Все что сможет ФС > - констатировать bad checksum. А восстановить это - не сможет. Наконец-то дошло! Ты делаешь успехи. А теперь прочти, что я написал РАНЕЕ про "zpool scrub poolname", что в результате его работы мы имеем. Не трудись: список повреждённых файлов с полными путями. Для вашего fsck, запускаемого по дефолту как "fsck -y", возможна только файло-помойка в каталоге /lost+found. > И > хорошо бы юзеру собрать то что от тома осталось и отрепайрить > до моунтабельного состояния, чтобы он не упирался, выколупывая останки файлов хексэдитором. Дело в том, что scrub обозначает повреждённые файлы и одновременно производит очистку ФС. И ФС после его работы считается де-факто в консистентном состоянии (свойство CoW + очистка scrub). Выколупывать какие-то ошмётки после scrub, конечно можно, они будут либо полностью отсутствовать, либо находиться по тем же путям, что и ранее имевшиеся файлы, даже имена файлов будут те же, но это уже будут не "те данные" — доставай из бэкапов, чуда не будет. --- Для сведения к минимуму риска повреждения данных в ZFS применяется расчет контрольной суммы, обеспечение избыточности данных и их самовосстановление. Тем не менее, повреждение данных может происходить в том случае, если пул не является избыточным, при повреждении во время нахождения пула в состоянии DEGRADED или в результате ряда маловероятных событий, приводящих к повреждению нескольких копий фрагмента данных. Вне зависимости от причины, результат одинаков: данные повреждены и, следовательно, недоступны. Предпринимаемое действие зависит от типа поврежденных данных и их относительной значимости. Возможно повреждение двух основных типов данных: * Метаданные пула – ZFS требует некоторых данных для открытия пула и обращения к наборам данных. При повреждении этих данных весь пул или целые ветви иерархии набора данных становятся недоступными. * Данные объектов – в этом случае повреждение происходит в рамках определенного файла или каталога. Эта проблема может привести к тому, что часть файла или каталога становится недоступной, или объект может оказаться полностью неработоспособным. Данные проверяются в нормальном режиме работы, а также в процессе очистки. --- Всё равно: в случае с ZFS у нас на руках список повреждённых/отсутствующих файлов ("zpool status -v"), а вслучае fsck —  сваленные в кучу "какие-то" ошмётки неизвестно чего в /lost+found. Вот и догадайся в последнем случае, что это было и что именно нужно восстановить. > Да, некоторые файлы могут быть испорчены. Хорошо если ФС или fsck > их как-то пометит как таковые. Но выцепить то что осталось с > тома проще всего когда он примонтирован, копированием. Для этого том должен > быть доведен до моунтабельного состояния. Утилитой-чекером. Ещё раз: "zpool import -F poolname" — импортирует полностью убитый (FAULTED) пул, если есть хоть малейшая надежда хоть что-то с него выцепить. fsck традиционных ФС в таких же случаях ничего не может предпринять кроме разрушения пользовательских данных ради приведения в порядок структуры ФС. > Кстати, а расскажи, как мне RAID в ноуте забабахать, если там чисто физически место для 1 HDD и более нишиша? В некоторых ноутбуках от SONY есть место для двух 2,5" HDD. Сам подумай, как можно сделать из них mirror. В обычных ноутбуках, как правило, место только для одного HDD/SSD. Тут уж не до избыточности, а вот верифицируемость данных важна, особенно на ненадёжных MLC SSD. >>> А почему RAID должен помогать в починке метаданных ФС? >> А почему нет, если он интегрирован с ФС? > Да хотя-бы потому что RAIDить может быть и некуда. Ну понятное дело > что ZFS не ориентирован на мелкие инсталляции "перец с ноутом", все > что они смогут сказать - "сам дурак". В настоящий момент я бы не отказался от ZFS на ноутбуке, у которого минимум 4 ГБ ОЗУ и процессор уровня двухъядерного AMD Athlon II 2 ГГц. Всё, что не слабее этой аппартаной конфигурации, должно довольствоваться UFS2 с Soft Updates или NTFS, но никак не динуксовыми ФС, теряющими данные на ровном месте. > А вот btrfs очень > даже ориентирован на такое применение. Поэтому там не катит говорить "сам > дурак". Там чинить придется, а потребовать пять дисков для рэйда - > не катит. Btrfs для высоких уровней RAID использует средства mdadm. До сих пор нет поддержки нативной реализации RAID-5. Только недавно в GRUB2 обеспечили возможность загрузки с Btrfs. Что ещё можно обсуждать? >> Конечно не панацея. Все привыкли к "обыденности", задаваемой "линуксовой братией". :)) > Просто btrfs рассчитан на немного более широкие сценарии, в частности и на > ноуты там всякие, где разместить многодисковый рэйд попросту негде. Так что > неизбежно придется отколупывать юзверям их диски из весьма неприглядного состояния и > скорее всего не имея зеркальной копии всех метаданных. >> Почему свою? Это ваша тупость, данная вам в ощущениях. > Мои ощущения говорят мне что мой ноут с 1 диском как-то сложно сделать осмысленным RAIDом. Вперёд, читать про восстановление ZFS после сбоев: http://download.oracle.com/docs/cd/E19253-01/820-0836/gavwg/...
	Ответить | Правка | ^ к родителю #208 | Наверх | Cообщить модератору

	220. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Michael Shigorin (ok) on 26-Июн-11, 21:40
	> Правда что ли? Неужели пробовал восстанавливать RAID из состояния FAULTED, > чтобы это говорить? Я -- да. > На mdraid это вообще бессмысленно. А Вы заканчивайте всё-таки свои чушебравады.  _Это_ как раз точно бессмысленно.
	Ответить | Правка | ^ к родителю #202 | Наверх | Cообщить модератору

	234. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от ананим on 27-Июн-11, 08:23
	прежде чем что-то там восстанавливать пусть вначале на ней ПО нормально работать начнёт. А то для примеру тот-же нжинкс до сих пор рекомендует её только для экстремалов. В отличие от кстати.
	Ответить | Правка | ^ к родителю #202 | Наверх | Cообщить модератору

	188. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 24-Июн-11, 23:01
	Включаешь либо избыточность по копиям параметром FS, либо делаешь зеркалирование одной командой. Законы сохранения и мануалы для тебя не писаны? Веришь в Деда Мороза?
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	209. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 25-Июн-11, 23:09
	> Включаешь либо избыточность по копиям параметром FS, либо делаешь зеркалирование одной > командой. И какой командой мне сделать чтобы на моем ноуте у меня зазеркалировались все данные+метаданные? Это что-то из разряда магии? :)
	Ответить | Правка | ^ к родителю #188 | Наверх | Cообщить модератору

	223. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Мяут (ok) on 27-Июн-11, 01:49
	# zfs set copies=2 tank Делает две копии данных и защищает от бедов
	Ответить | Правка | ^ к родителю #209 | Наверх | Cообщить модератору

	112. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от anonymous (??) on 23-Июн-11, 23:49
	> Правда, не похоже на унылый fsck традиционных ФС? ;) конечно, не похоже: унылые fsck традиционных ФС ещё и восстанавливать данные умеют. а проверку чексум написать — дело нехитрое.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	119. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–1 +/–
	Сообщение от iZEN (ok) on 24-Июн-11, 00:50
	>> Правда, не похоже на унылый fsck традиционных ФС? ;) > конечно, не похоже: унылые fsck традиционных ФС ещё и восстанавливать данные умеют. Ага — cкладывать горкой в .lost-found неназванный мусор. :)) > а проверку чексум написать — дело нехитрое. Чего ж до сих пор не написали, чтобы fsck для традиционной ФС выводил полный список повреждённых файлов, а не молчком складировал "чего-то найденное, опознанное как файлы" в .lost-found?
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	199. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от Аноним (??) on 25-Июн-11, 13:37
	> Ага — cкладывать горкой в .lost-found неназванный мусор. :)) Проблема лишь в том что если все настолько плохо, том скорее всего совсем не смонтируется или не протянет долго будучи примонтированным, так что без fsck в той же ситуации ты сам будешь этот мусор еще и собирать хексэдитором со всех закоулков диска, лично парся дисковые структуры. Что и можно понаблюдать где-то типа http://www.lissyara.su/articles/freebsd/file_system/zfs_reco.../ - это еще повезло, все было легко и очевидно. Могло быть гораздо хуже, как то бэд где-то посередине диска. > Чего ж до сих пор не написали, чтобы fsck для традиционной ФС > выводил полный список повреждённых файлов, а не молчком складировал "чего-то найденное, > опознанное как файлы" в .lost-found? Наверное, потому что удалось опознать нечто как похожее на файл, но не удалось понять кому оно принадлежало? Или ты как наивный чукотский юноша думаешь, что в lost+found файлы складывают чтобы пользователю насолить? :)
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	174. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 24-Июн-11, 12:50
	> Правда, не похоже на унылый fsck традиционных ФС? ;) Да уж. Унылый fsck по задумке еще и репайрит порушенные метаданные до более-менее моунтабельного состояния. Чтобы структуры (то что от них уцелело) разбирал бы все-таки драйвер ФС а не юзверь с хексэдитором. Потому что второй вариант "немного" сложнее и медленнее. А у вас я такой задумки не вижу. И что-то мне не нравится перспектива пересобирать 100500 гиговый пул если умерло всего 2 несущественных файла на 5Кб.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	186. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от iZEN (ok) on 24-Июн-11, 15:51
	>> Правда, не похоже на унылый fsck традиционных ФС? ;) > Да уж. Унылый fsck по задумке еще и репайрит порушенные метаданные до > более-менее моунтабельного состояния. Чтобы структуры (то что от них уцелело) разбирал > бы все-таки драйвер ФС а не юзверь с хексэдитором. Потому что > второй вариант "немного" сложнее и медленнее. А у вас я такой > задумки не вижу. Увидь: http://compute.cnr.berkeley.edu/cgi-bin/man-cgi?zpool+1 --- zpool import -F poolname -F              Recovery mode for a non-importable pool. Attempt  to              return the pool to an importable state by discarding              the last few transactions. Not all damaged pools can              be  recovered  by  using this option. If successful,              the data from the discarded  transactions  is  irre-              trievably  lost.  This option is ignored if the pool              is importable or already imported. Example 15 Recovering a Faulted ZFS Pool      If a pool is faulted but recoverable, a  message  indicating      this  state  is  provided  by  zpool  status if the pool was      cached (see cachefile above), or as part of the error output      from a failed zpool import of the pool.      Recover a cached pool with the zpool clear command:        # zpool clear -F data        Pool data returned to its state as of Tue Sep 08 13:23:35 2009.        Discarded approximately 29 seconds of transactions.      If the pool configuration was not cached, use  zpool  import      with the recovery mode flag:        # zpool import -F data        Pool data returned to its state as of Tue Sep 08 13:23:35 2009.        Discarded approximately 29 seconds of transactions. ---
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

	200. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 25-Июн-11, 13:42
	И что в этой копипасте предлагается увидеть? То что реализован аж целый один метод рекавери для целой одной ситуации когда что-то пошло не так в самых последних транзакциях? Дык это не аналог fsck, это костылик для одной конкретной ситуации. Те же бэдсектора вовсе не давали обязательств попадать только в последние транзакции, а не куда-то в середину. А откатывать полтома в вид каким оно было 2 месяца назад - как-то уже не то.
	Ответить | Правка | ^ к родителю #186 | Наверх | Cообщить модератору

	201. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–1 +/–
	Сообщение от iZEN (ok) on 25-Июн-11, 17:16
	> И что в этой копипасте предлагается увидеть? То что реализован аж целый > один метод рекавери для целой одной ситуации когда что-то пошло не > так в самых последних транзакциях? Не поможет — zdb в зубы и вперёд.
	Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору

	210. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Аноним (??) on 25-Июн-11, 23:13
	> Не поможет — zdb в зубы и вперёд. Лучше уж fsck, имхо. Он большую часть типовых проблем чинит автоматически, а там где это невозможно - запрашивает пользователя что ему сделать.
	Ответить | Правка | ^ к родителю #201 | Наверх | Cообщить модератору

	215. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от iZEN (ok) on 26-Июн-11, 07:58
	> запрашивает пользователя что ему сделать. У него вопрос один: "Чинить или не чинить?" — и то, файловую систему, а не файлы (файлы ему как-то похеру).
	Ответить | Правка | ^ к родителю #210 | Наверх | Cообщить модератору

	238. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Anon Y Mous on 27-Июн-11, 17:20
	>> Не поможет — zdb в зубы и вперёд. > Лучше уж fsck, имхо. Он большую часть типовых проблем чинит автоматически, а Список типовых проблем, которые btrfsck чинит можно в студию? А то как бы не оказалось, что все что он делает - это аналог 'zpool import -F'.. > там где это невозможно - запрашивает пользователя что ему сделать. Ну-ну - вы уж определитесь, толи fsck для пользователя, толи пользователь для fsck :)
	Ответить | Правка | ^ к родителю #210 | Наверх | Cообщить модератору

	150. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	–1 +/–
	Сообщение от Anon Y Mous on 24-Июн-11, 09:29
	> А у btrfs он пока попросту бесполезный т.к. сырой еще напрочь - его только сделали. Да-да, ZFS нет никакой zfsc, а у btrfs есть. А то, что этот чинящий что-то там btrfsck никто еще толком не видел, и что он там умеет чинить никто не знает - это фигня, главное команда такая есть :) У btrfs был шанс - ровно до тех пор, пока не начали делать fsck. Теперь вместо тестирования файловой системы чуваки занимаются тестированием fsck: https://fedorahosted.org/fesco/ticket/594#comment:2 > Recovery strategy - A fsck tool is almost ready, part of the reason it is taking so long is it is being very well > tested, so when it does ship it will have been run through several hundred broken fs's to make sure it works > properly. Теперь ее участь - корневая ФС на крохотных раздельчиках, не более :)
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	175. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
	Сообщение от Аноним (??) on 24-Июн-11, 12:53
	> что он там умеет чинить никто не знает - это фигня, > главное команда такая есть :) Ну так научат, фигли. Быстро только языком на форуме тарахтеть. > У btrfs был шанс - ровно до тех пор, пока не начали делать fsck. До тех пор никто ее на серверах и десктопах всерьез рассматривать даже не стал бы. > Теперь вместо тестирования файловой системы чуваки занимаются тестированием > fsck: https://fedorahosted.org/fesco/ticket/594#comment:2 Жирно слишком. Ченжлоги к кернелу не подтверждают ваш тезис. А fsck тоже тестировать надо - мы хотим возможность отремонтировать ФС даже если оно все-таки каким-то чудом навернется. > Теперь ее участь - корневая ФС на крохотных раздельчиках, не более :) Я бы сказал, "она будет работать в том числе и на крохотных раздельчиках". Спасибо Шишкину и Ко..
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	236. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
	Сообщение от Anon Y Mous on 27-Июн-11, 15:56
	> До тех пор никто ее на серверах и десктопах всерьез рассматривать даже не стал бы. Странно. Мне вот  вот все равно, есть fsck или нет, ибо ее наличие дает разве что возможность бездарно потерять еще кучу времени с непредсказуемым результатом, вместо того начать восстанавливаться из бэкапа. Вот отсутствие аналога ztest для btrfs - это гораздо хуже. Хотя может я отстал от жизни и аналог таки уже есть. > Жирно слишком. Ченжлоги к кернелу не подтверждают ваш тезис. Жирно слишком у тебя в черепной коробке, все мозги жиром заплыли :) >> Теперь ее участь - корневая ФС на крохотных раздельчиках, не более :) > Я бы сказал, "она будет работать в том числе и на крохотных раздельчиках". Спасибо Шишкину и Ко.. Речь о том, что для ФС размером в сотни терабайт и больше время fsck становится неприлично большим, так что есть она или нет - не так важно. Важно то, что вместо нормального тестирования самой ФС ребята занимаются ерундой и тестируют fsck. А наличие fsck развращает - всегда есть воcпользоваться fsck чтобы "восстановить хоть что-то", вместо того, чтобы разобраться, что же собственно не так. И при ее наличии устоять против этого соблазна будет ой как непросто. Поэтому я и говорю, у btrfs  был шанс стать системой для ФС любых объемов - от крохотных до огромных. А так остаются только крохотные, где fsck сможет отработать за разумное время, да и там, как показал Шишкин, есть проблемы :)
	Ответить | Правка | ^ к родителю #175 | Наверх | Cообщить модератору

88. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+1 +/–
Сообщение от Аноним (??) on 23-Июн-11, 20:24
Кстати btrfsck уже научился исправлять ошибки?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

106. "Изучение изменения размера кодовой базы Ext4, Btrfs и XFS"	+/–
Сообщение от gegMOPO4 (ok) on 23-Июн-11, 22:55
В этих 39% комментариев учтены стандартные заголовки файлов с указанием копирайтов и ссылкой на GPL?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема