| 1.1, Аноним (-), 16:08, 27/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Вообще-то поведение "repair" должно не опцией включаться. А, с учетом назначения утилиты, быть дефолтным поведением при указании в качестве аргумента точки монтирования.
| | |
| |
| 2.3, Аноним (-), 16:12, 27/02/2012 [^] [^^] [^^^] [ответить]
| +7 +/– | |
> Вообще-то поведение "repair" должно не опцией включаться. А, с учетом назначения утилиты, быть дефолтным поведением при указании в качестве аргумента точки монтирования.
Почитайте man fsck в вашей ОС, там изложены несколько иные взгляды.
| | |
| 2.60, Аноним (-), 01:56, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> А, с учетом назначения утилиты, быть дефолтным поведением при указании в качестве аргумента точки монтирования.
Как бы тебе объяснить то? Ты будешь готов скушать далеко не любой результат работы таковой утилиты. Иногда таким утилитам "по статусу положено" принимать потенциально проблемные решения, так что вопрос о дефолтах довольно философский.
| | |
|
| 1.2, Аноним (-), 16:10, 27/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Также отмечается о создании отдельной экспериментальной ветки в Git-репозитрии Btrfs
> ветка получила название "dangerdonteveruse"
Хм. Бранч с таким названием в репе btrfs-progs лично я помню уже как минимум месяц.
| | |
| 1.4, Васька. (?), 16:17, 27/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– |
Непонятно, зачем сжатие файловой системе? Хранить в два, ну почти три раза больше данных :-( данные данным рознь, не получится из этого ничего хорошего.
| | |
| |
| 2.5, Блуд (??), 16:24, 27/02/2012 [^] [^^] [^^^] [ответить]
| +9 +/– |
Всё очень просто. Храня сжатые данные, требуется меньше времени на их считывания. А учитывая, что жёсткий диск является медленным устройством, то сжатие - большой плюс!
| | |
| |
| |
| 4.17, Аноним (-), 16:48, 27/02/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
При рандомном доступе к многотерабайтному массиву, для более-менее эффективной работы размер кэша должен быть сопоставим с размером массива. Во-первых, дорого, во-вторых, неустойчиво к сбоям. Порочность этого пути хорошо видна на примере ZFS, которая выдает приемлемую производительность только в "режиме стримера" (т.е. исключительно при линейном доступе).
| | |
| |
| 5.41, Аноним (-), 19:21, 27/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Как рандомно обратиться к запакованным данным? Сперва секцию с данными целиком прочитать, потом распаковать, потом только обратиться к нужному месту. Рандомное обращение - плохой пример.
| | |
| |
| 6.58, VoDA (ok), 01:08, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > Как рандомно обратиться к запакованным данным? Сперва секцию с данными целиком прочитать,
> потом распаковать, потом только обратиться к нужному месту. Рандомное обращение -
> плохой пример.
Много-пользователей читает множество файлов. Или раздача web-статики. Получается стучимся в радномные файлы (часто малого размера). На этом как раз кэш в холостую работает, а сжатие данных очень полезно.
| | |
| 6.63, Аноним (-), 01:59, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Как рандомно обратиться к запакованным данным?
Так же как и к остальным - никто не жмет огромные блоки. Сжатие идет небольшими кусками, чего впрочем вполне хватает для профита на рыхлых данных. Да, 7zip сожмет покруче. И даже очень. Вот только скорость... ;)
| | |
|
|
| 4.62, Аноним (-), 01:58, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Больше кэшей! Больших и разных.
В данном случае выигрыш за счет того что меньше данных читать-писать, а алгоритм крайне быстр и может существенно обгонять накопитель.
| | |
| |
| 5.71, Аноним (-), 08:04, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
А еще это решение является концептуальным в своем роде. Подумайте сами - с ростом производительности системы можно встраивать в btrfs более "тяжелые" алгоритмы при этом лишь надо соблюсти соотношение скорость сжатия/распаковки со скоростью чтения/записи на носитель.
| | |
| |
| 6.72, Аноним (-), 08:23, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> с ростом производительности системы можно встраивать в btrfs более "тяжелые" алгоритмы
Ну вот zlib зачастую не поспевает за накопителем, т.к. 2-ступенчатый (LZ -> huffman). А вот эти алгоритмы - быстрые, распаковка такой штуки вообще напоминает немного продвинутый вариант memcpy. Поэтому обычно они (LZO, Snappy, LZ4) - шустрее. Накопители, btw, тоже на месте не стоят: появились ssd которым 6Гбит sata - мало, так что они в pci-e втыкаются. Стоят конечно конских денег, но ведь и скорость - под стать...
| | |
| |
| 7.88, Аноним (-), 17:17, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
А как насчет LZMA ? ИМХО, кажется он совершенно пригоден для сжатия на уровне фс (ядра-то мы давно уже сжимаем им).
| | |
| |
| 8.90, arisu (ok), 17:23, 28/02/2012 [^] [^^] [^^^] [ответить] | +/– |  с дуба рухнул, штоле скорость сжатия ужасающа, скорость разжатия ужасающа ... текст свёрнут, показать | | |
| 8.117, Аноним (-), 17:36, 05/03/2012 [^] [^^] [^^^] [ответить] | +/– | Хоть его и портировали на чистый си в конце концов и даже в виде годном для пиха... большой текст свёрнут, показать | | |
|
|
|
|
|
|
| 2.7, Анонут (?), 16:28, 27/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
Да,да вспоминаются времена dblspace под досом. Когда можно было из 40Мб сделать как-бэ 120Мб. Реально влезало на 1-2Мб больше. При малейшем сбое на винте - данные терялись чуть менее чем все.
Может сейчас оно уже не так ужасно. Прогресс всетаки.
| | |
| |
| 3.15, inferrna (?), 16:43, 27/02/2012 [^] [^^] [^^^] [ответить]
| +4 +/– |
Ну, во-первых, там и в 95-98 винде сжимался вроде-как весь диск и при внешнем монтировании это дело выглядело как 1 большой файл и горстка маленьких. Тут, всё-таки, сжимаются отдельные файлы. Во-вторых, по-умолчанию там "compress highly compressible files, but back off and blacklist incompressible content".
| | |
| 3.73, Аноним (-), 08:31, 28/02/2012 [^] [^^] [^^^] [ответить] | +/– | Реально - зависело от того что там хранить Понятный пень что уже сжатые жыпеги ... большой текст свёрнут, показать | | |
|
| 2.9, x0r (??), 16:30, 27/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
ну если не сжалось - можно и записать как есть.
| | |
| 2.51, Аноним (-), 00:10, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
ты видел сколько бдрипы стартрека занимают? в ноут такой диск пока не впихнёшь.
| | |
| |
| 3.77, arisu (ok), 12:01, 28/02/2012 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> ты видел сколько бдрипы стартрека занимают?
во времена TOS никакого «б» не было. а остальным место в помойке.
| | |
|
| 2.61, Аноним (-), 01:57, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Непонятно, зачем сжатие файловой системе?
Скорость записи и особенно чтения с столь скоростными алгоритмами может быть _быстрее_ чем скорость чтения-записи несжатых файлов. Просто потому что читать-писать меньше и если все упиралось в накопитель, ему внезапно полегчает в пару раз -> PROFIT.
| | |
|
| 1.8, x0r (??), 16:28, 27/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
"устойчива к сбоям, тем не мнее потребность в fsck вызвана возможностью появления повреждений, вызванных внешними факторами"
Типа космические архитекторы столкнулись с реальностью? Они заметили, что:
1) при их методах использования двоичных деревьев - дофига места тратится на метаинформацию.
2) FS все таки может повреждаться так, что автоматическое восстановление не помогает...
| | |
| |
| 2.13, Аноним (-), 16:40, 27/02/2012 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> 2) FS все таки может повреждаться так, что автоматическое восстановление не помогает...
Сообщите это разработчикам ZFS, пожалуйста. Они до сих пор не могут себе такого представить.
| | |
| |
| 3.25, Аноним (-), 17:28, 27/02/2012 [^] [^^] [^^^] [ответить]
| –9 +/– |
>> 2) FS все таки может повреждаться так, что автоматическое восстановление не помогает...
> Сообщите это разработчикам ZFS, пожалуйста. Они до сих пор не могут себе
> такого представить.
В линюкс эта фс входит в штатное ядро? Уже можно пользоваться "из коробки" и без лишних телодвижений, как extx, jfs, xfs? Что-то в том же руководстве по генту о ней ни слова...
Ой, так вы о той самой фс, у которой проблемы с лицензией под линюкс? Которая требует или патча на ядро, или использования ее в fuse? Экое счастье - оставьте его тем, кому оно надо - инвалидам на костылях. А мы btrfs прекрасно будем пользоваться ;) Даже без btrfsch - благо, она уже достаточно надежно работает и без fsck.
| | |
| |
| 4.31, Аноним (-), 18:29, 27/02/2012 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Которая требует или патча на ядро, или использования ее в fuse?
zfsonlinux легко и непринужденно собирается модулем. Но зачем тащить в линукс это кривое тормозилово?
> Даже без btrfsch - благо, она уже достаточно надежно работает и без fsck.
Да, ZFS при сбоях данные убивает надежно и намертво.
А ее разработчики zfschk не осилили, поэтому придумывают сказки, что оно не нужно.
| | |
| |
| 5.37, iZEN (ok), 18:59, 27/02/2012 [^] [^^] [^^^] [ответить]
| –6 +/– |
 > Да, ZFS при сбоях данные убивает надежно и намертво.
Что вы врёте и не краснеете?
При сбоях ZFS теряются только те данные (файлы), которые были повреждены (случайный dd по файловой системе, например). Метаинформация многократно дублируется. Остальные файлы будут целы. Убитый пул RAID-Z после импортирования с ключом "-F" и scrub'а может быть живым, лишившись лишь части файлов - http://forum.ixbt.com/topic.cgi?id=11:43009-163#4797
| | |
| |
| 6.48, Аноним (-), 23:36, 27/02/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> При сбоях ZFS теряются только те данные (файлы), которые были повреждены (случайный dd по файловой системе, например). Метаинформация многократно дублируется. Остальные файлы будут целы. Убитый пул RAID-Z после импортирования с ключом "-F" и scrub'а может быть живым, лишившись лишь части файлов
Теоретики, такие теоретики...
| | |
| |
| 7.95, iZEN (ok), 18:33, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Теоретики, такие теоретики...
Дык, практики. Всё опробовано и выяснено на деле.
| | |
| |
| |
| 9.109, iZEN (ok), 21:09, 28/02/2012 [^] [^^] [^^^] [ответить] | +/– | Я сталкивался со сбоями ZFS После scrub а повреждённого пула у меня был список ... текст свёрнут, показать | | |
|
|
|
| 6.78, arisu (ok), 12:04, 28/02/2012 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Метаинформация многократно дублируется.
а я покупал диски, чтобы данные хранить, а не «метаинформацию»…
| | |
| |
| 7.91, iZEN (ok), 18:28, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> а я покупал диски, чтобы данные хранить, а не «метаинформацию»…
Этот перл адресуйте разработчикам Btrfs — там метаинформации как раз довольно много. ;)
| | |
| |
| 8.100, Аноним (-), 19:08, 28/02/2012 [^] [^^] [^^^] [ответить] | –1 +/– | А в ZFS ее столько же, плюс еще она дублируется 100500 раз хотят толку от этого... текст свёрнут, показать | | |
| |
| 9.108, iZEN (ok), 19:49, 28/02/2012 [^] [^^] [^^^] [ответить] | +/– | Откуда вы это знаете Где проходили В ZFS 128k-блоки по умолчанию данных и ме... большой текст свёрнут, показать | | |
|
| |
| 9.113, iZEN (ok), 21:42, 01/03/2012 [^] [^^] [^^^] [ответить] | +/– | Читал http docs oracle com cd E19253-01 820-0836 gbchp index html http www ... текст свёрнут, показать | | |
|
|
|
|
| 5.38, Аноним (-), 19:02, 27/02/2012 [^] [^^] [^^^] [ответить]
| +3 +/– | |
+1
У меня бтр под Linux 98 ваще летает, а ZFS ацтой, постоянно глючил на дискетах 1.44".
| | |
|
| 4.40, zhuk (?), 19:18, 27/02/2012 [^] [^^] [^^^] [ответить]
| +2 +/– |
А чтож ты, деточка, не представился? Засцал с izen'ом в открытую поговорить?))))
| | |
|
|
| 2.64, Аноним (-), 02:01, 28/02/2012 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> 2) FS все таки может повреждаться так, что автоматическое восстановление не помогает...
Ну вон ZFSники жрут кактус и уже который год толкают пиар что мол это все гон и такие утили нам не нyжны...
| | |
| |
| 3.92, iZEN (ok), 18:29, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> 2) FS все таки может повреждаться так, что автоматическое восстановление не помогает...
> Ну вон ZFSники жрут кактус и уже который год толкают пиар что мол это все гон и такие утили нам не нyжны...
Кактус ли это?
| | |
| |
| 4.102, Аноним (-), 19:11, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Кактус ли это?
Лично мне кажется, что склонная к неожиданным смертям файлуха без fsck - явный кактус. Поэтому на ZFS не рвусь.
У вас, конечно, может быть другое мнение =)
| | |
|
|
|
| |
| |
| 3.23, Sergey722 (ok), 17:20, 27/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
 Да фигня. Хотели к дню святого Валентина, а сделают к 8 марта (ну на крайняк к 9 мая).
| | |
| |
| 4.35, Аноним (-), 18:36, 27/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Да фигня. Хотели к дню святого Валентина, а сделают к 8 марта
> (ну на крайняк к 9 мая).
Вопрос только, какого года? Явно, что не этого.
| | |
| |
| 5.45, Serrgey722too (?), 22:52, 27/02/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Вопрос только, какого года? Явно, что не этого.
Да не, я верю. К дню победы БТР должны подогнать. Он проедет по красной площади.
| | |
| |
| 6.49, Аноним (-), 23:38, 27/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Да не, я верю. К дню победы БТР должны подогнать. Он проедет по красной площади.
Да, к 70-му юбилею. Ну в крайнем случае к 75-му.
| | |
|
|
|
|
| |
| 3.22, Sergey722 (ok), 17:12, 27/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Да я в курсе. Просто её пилят чуть ли не столько же сколько я линуксом пользуюсь. Последнее время с новостями зачастили. И вот я думаю, это признак того, что счастье уже близко или просто статистический выброс.
| | |
| |
| 4.24, Аноним (-), 17:24, 27/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Просто люди устали ждать, интерес к проекту сильно подогрет, поэтому любые достижения, даже сомнительного свойства, вызывают искреннюю радость :)
| | |
| |
| 5.34, Аноним (-), 18:35, 27/02/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Просто люди устали ждать, интерес к проекту сильно подогрет, поэтому любые достижения, даже сомнительного свойства, вызывают искреннюю радость :)
Лично для меня разработка btrfs - это такой комедийный сериал, по длительности сравнимый с санта-барбарой. Прочитать очередную 100500-ю новость про "скоро допилим", посмеяться, и пойти дальше юзать ext4/xfs@lvm@mdraid.
| | |
| |
| 6.66, Аноним (-), 02:02, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Лично для меня разработка btrfs - это такой комедийный сериал, по длительности
> сравнимый с санта-барбарой. Прочитать очередную 100500-ю новость про "скоро допилим",
> посмеяться, и пойти дальше юзать ext4/xfs@lvm@mdraid.
"Сначала над вами смеются, потом с вами борятся, а потом вы побеждаете..."
| | |
| |
| 7.81, Аноним (-), 14:26, 28/02/2012 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> "Сначала над вами смеются, потом с вами борятся, а потом вы побеждаете..."
Это не про разработку btrfs.
Про разработку btrfs будет так: "Сначала над вами смеются, потом над вами смеются, а потом над вами смеются снова..."
| | |
|
| 6.79, arisu (ok), 12:07, 28/02/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
для тебя вообще разработка — комедийный сериал, видимо. «и что вы мучаетесь, дурачки? ведь всё уже давно написано, больше ничего делать не надо!»
| | |
| |
| 7.82, Аноним (-), 14:27, 28/02/2012 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> для тебя вообще разработка — комедийный сериал, видимо.
Если у разработчиков руки из задницы, то да.
| | |
|
|
|
| 4.54, Клыкастый (ok), 00:16, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > Да я в курсе. Просто её пилят чуть ли не столько же
> сколько я линуксом пользуюсь. Последнее время с новостями зачастили. И вот
> я думаю, это признак того, что счастье уже близко или просто
> статистический выброс.
на самом деле это очень хорошо. пилят - это здорово.
| | |
|
|
|
| 1.26, ArtKun (?), 17:53, 27/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Хорошо, что перенесли на F18. Летом не придется переустанавливать систему, а к Новому году можно будет таки перевести на нее все диски.
| | |
| 1.27, Аноним (-), 17:55, 27/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
То что Btrfs скоро будет в Fedora по умолчанию, это еще не признак того что она готова к продакшену. Да и как бы там не было, хотелось бы иметь гарантию в лице fsck, в случае проблем с ФС
| | |
| |
| 2.28, nagual (ok), 18:07, 27/02/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > То что Btrfs скоро будет в Fedora по умолчанию, это еще не
> признак того что она готова к продакшену. Да и как бы
> там не было, хотелось бы иметь гарантию в лице fsck, в
> случае проблем с ФС
И почему то все скромно умалчивают что этой хрени так же как и zfs нужен гиг под кеш Ж-)) иначе все будет очень грустно ...
| | |
| |
| 3.29, Дворник (??), 18:16, 27/02/2012 [^] [^^] [^^^] [ответить]
| –3 +/– |
Ну как бы это помягче сказать... Если у вас нет возможности купить 1G RAM в наше время, то в самый раз подумать о том, что в жизни что-то не так. ;)
| | |
| |
| |
| 5.55, Клыкастый (ok), 00:19, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Не все ноутбуки можно легко обновлять.
это да. с другой стороны 90% купивших ноутбуки ставят их на стол "они занимают меньше места". с учётом толковой мыши и часто клавы - больше, но ведь это мелочи. И батареи садятся через год. И ремонтопригодность не ахти. И апгрейд не особо.
| | |
|
| 4.32, Анон (?), 18:34, 27/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
Это если у вас файлохранилище выделенное. А если на той системе, где куча ещё всего?
| | |
| 4.43, анон (?), 20:19, 27/02/2012 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Если у вас нет возможности купить 1G RAM в наше время, то в самый раз подумать о том, что в жизни что-то не так
Это не золотые часы и не брюлики, чтобы что-то доказывать и понтоватья.
Сугубо инженерная задача - эффективная эксплуатация имющихся ресурсов. btrfs с ней не справляется.
| | |
| |
| 5.59, VoDA (ok), 01:12, 28/02/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Если у вас нет возможности купить 1G RAM в наше время, то в самый раз подумать о том, что в жизни что-то не так
> Это не золотые часы и не брюлики, чтобы что-то доказывать и понтоватья.
> Сугубо инженерная задача - эффективная эксплуатация имющихся ресурсов. btrfs с ней не
> справляется.
вам не подходит - не пользуйтесь.
те, кому интересен прирост производительность, CoW или другие фишки btrfs поставят требуемое количество памяти. остальным просто стоит продолжить пользоваться ext4/
| | |
| 5.75, Аноним (-), 08:35, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> btrfs с ней не справляется.
А как это проверялось? Делались какие-то бенчи? Тогда методику, версию ядер и результаты - в студию. А то ископаемости с фороникса уже давно заржавели...
| | |
|
|
| 3.36, Аноним (-), 18:41, 27/02/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> И почему то все скромно умалчивают что этой хрени так же как и zfs нужен гиг под кеш Ж-)) иначе все будет очень грустно ...
Это подразумевается by default - за плюшки cow надо платить. Не только размером кеша, необходимого для приемлемой скорости, но и размером метаданных на диске.
Пока что не созданы cow fs, лишенные этих недостатков.
| | |
| |
| 4.46, anonymous (??), 23:21, 27/02/2012 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Не в CoW дело. Бтрфс даже сам Линус пропиарил, что то там про "пару лет потерпите с ext4 а потом будет только одно сплошное btrfs". Было это давно, как раз тогда SSD сверхмодные были и ктото запилил поддержку особенностей SSD в btrfs. Тест ессно был шоковым по скорости, народ на этой волне впал в эйфорию и вот уже четвертый год никик понять не могут в чем прокол. НЕ поймут и в следующем году, увы.
Лично мне вот просто жутко понравилось сквозные контрольные суммы, и заявленая ускоренная работа при fsync. Ну нет бабла на аппаратный рейд с батарейкой и всякие ECC RAM, я обычный домашний пользователь без особых претензий. Но вот хотелось бы знать когда данные считаные с диска протухли, причем автоматом без услилий с моей стороны и бесплатно. Причем контроль на всем пути от поверхности диска до памяти. Хорошая ведь идея, журнал Ext4 тоже переделывают под это дело, но лучше бы все данные а не только журнал.
А в итоге получаешь какой то прикол, та самая фича ускоренного fsync на самом деле оказалась костылем прикрученым изолентой для маскировки плохой общей организации системы, и по факту попробуй потыкай каждый день раза 3 git fetch; git rebase на дереве исходников gcc, это же песня. Не говоря об банальном yum update.
Что то я снова разошелся. Ну так на самом деле обидно, разбег на рубль удар на копейку.
| | |
| |
| 5.50, Аноним (-), 23:43, 27/02/2012 [^] [^^] [^^^] [ответить] | +/– | Защиту данных на пути от диска до памяти неплохо обеспечивает написанный ораклом... большой текст свёрнут, показать | | |
| |
| 6.57, anonymous (??), 00:55, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
Так я то же самое и говорю, хочется чтобы оно из коробки, по умолчанию, просто скачал Федору установил и все. По дефолту даже не для упрощения моей жизни (хотя это конечно тоже), а как косвенная гарантия что не я один в одной лодке и если что то пойдет не так на форумах будет шум, и более быстрое решение.
Насчет чексумм не соглашусь, это еще и бесплатная дополнительная проверка дешевого домашнего железа, с этой фичей раньше прокукарекает что блок питания сыпется и так далее.
| | |
| |
| 7.70, Аноним (-), 03:27, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> косвенная гарантия что не я один в одной лодке
Поверь, в этой лодке будет как минимум половина местных через энное время :). А то что не всем дано быть тестовыми пилотами - это нормально.
| | |
|
| 6.87, iZEN (ok), 17:15, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Защиту данных на пути от диска до памяти неплохо обеспечивает написанный ораклом
> еще в 2007 году LDIF. А на диске их целостность контролирует
> контроллер диска.
Контроллёр диска контролирует только СОХРАНЕНИЕ данных, но не всё время их жизни. Увы.
> Вообще, сквозное чексуммирование по блокам (можно и с дедупликацией), при необходимости,
> легко и непринужденно делается средствами device-mapper, в виде обычного блочного устройства,
> которое выдает read error, если сумма данного блока битая.
> Но вот
> только это никому не нужно - сколько ни чексуммируй данные, все
> равно остается тот уровень, когда они не защищены и возможна ошибка.
Недавно новость пробегала, что в Linux md-RAID всё-таки внесли исправления на предмет определения разности прочитанных блоков в конфигурации с RAID-1 и вывода сообщения об ошибке чтения с массива. Лично я не проверял эту новую фичу и хочу выслушать мнение пользователей, которые с такой особенностью уже столкнулись: как они решали проблему восстановления битых данных, если с зеркальных "плоскотей" RAID-1 были прочитаны отличающиеся блоки данных? Ведь в этом случае информация о верности того или иного блока должна браться с "верхнего" уровня — уровня файловой системы. Только на файловой системе ведутся подсчёты контрольных сумм для "кластеров" (в терминах Windows, совокупности секторов носителей), то есть блоков самой ФС.
| | |
| |
| 7.89, arisu (ok), 17:22, 28/02/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
вообще-то вылазь из подвала: data integrity вполне себе контролирует сам рейд. и он способен сказать, откуда прочитали фигню, а откуда то, что записывали.
| | |
| 7.104, Аноним (-), 19:17, 28/02/2012 [^] [^^] [^^^] [ответить] | +/– | Почему вы так любите рассуждать на темы, в которых не разбираетесь FYI практич... большой текст свёрнут, показать | | |
| |
| 8.107, iZEN (ok), 19:37, 28/02/2012 [^] [^^] [^^^] [ответить] | +/– | Угу Пример с md-RAID несколькогодичной давности http www linux org ru news b... текст свёрнут, показать | | |
|
|
|
| 5.69, Аноним (-), 03:22, 28/02/2012 [^] [^^] [^^^] [ответить] | +/– | ИЧСХ, примерно так и будет Для тупых объясняю большие и масштабные штуки не д... большой текст свёрнут, показать | | |
| |
| 6.111, Genix (?), 23:19, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> Не говоря об банальном yum update.
> А что, он умеет не тормозить хоть на какой-то ФС?
По-моему, автор жалуется на то что мир меняется быстрее его понимания, а не то что ФС тормозит при yum update =)
| | |
|
|
|
| 3.67, Аноним (-), 02:04, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> И почему то все скромно умалчивают что этой хрени так же как и zfs нужен гиг под кеш Ж-))
Ну вообще-то ряд моментов там сделан менее дебильно и оно будет пожалуй пошустрее ZFS если гига под кеш не нашлось. Если кому интересно, у фороникса бенчей - есть. Правда баянные.
| | |
|
|
| |
| 2.68, Аноним (-), 02:06, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Так и когда я смогу сделать compress=lz4 ??
Да хоть прям ща, наложив патчи, если тебе позарез охота.
| | |
|
| 1.42, Аноним (-), 19:29, 27/02/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Блин, лучше такими усилиями Reiser4 пилили, тогда уже давно вменяемую современную ФС имели бы. Блин, почему Гансу работать запретили(
| | |
| |
| 2.80, arisu (ok), 12:19, 28/02/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
вперёд — убеждай народ, собирай энтузиастов. а если убедишь какую-нибудь контору — ещё и денег дадут.
| | |
| 2.84, Аноним (-), 14:33, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Блин, лучше такими усилиями Reiser4 пилили, тогда уже давно вменяемую современную ФС
А что в ней такого современного? Разве она по фичам значительно превосходит ext? Снапшоты, сквозное чексуммирование, онлайновые ресайз и дефраг, оптимизация под SSD?
| | |
|
| |
| 2.83, Аноним (-), 14:30, 28/02/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> а нафига в cow файловой системе fsck?
В cow fs fsck нужен как и в других. Просто разработчики одной известной cow fs поленились (или не осилили) написать fsck, и придумали сказку, что оно там не нужно. С тех пор и гуляет миф в народе.
| | |
| |
| 3.94, iZEN (ok), 18:32, 28/02/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> а нафига в cow файловой системе fsck?
> В cow fs fsck нужен как и в других. Просто разработчики одной
> известной cow fs поленились (или не осилили) написать fsck, и придумали
> сказку, что оно там не нужно. С тех пор и гуляет
> миф в народе.
scrub — это и есть fsck с другим названием.
| | |
| |
| 4.114, Аноним (-), 16:34, 05/03/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> scrub — это и есть fsck с другим названием.
Угу. И менее дотошный/способный к починке раздестроенного тома. Иначе сообщений типа того что на лисяре просто не возникало бы как класса.
| | |
| |
| 5.116, iZEN (ok), 17:17, 05/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> scrub — это и есть fsck с другим названием.
> Угу. И менее дотошный/способный к починке раздестроенного тома.
Ты вообще различаешь DEGRADED и FAULTED состояния системы хранения?
scrub в обычном применении лечит DEGRADED.
В необычном применении — после "zpool import -F faultedpoolname" scrub может лечить FAULTED-пул, импортированный "как есть", в режиме DEGRADED, если это возможно.
Если три из четырёх копыт отброшены, то никакой fsck, ни scrub ни на каком RAID кроме mirror ничего тебе не пролечит, а откажется выполняться.
> Иначе сообщений типа того что на лисяре просто не возникало бы как класса.
В то время для импорта FAULTED пула не было опции "-F" для автоматической пробы и отмотки состояния пула от FAULTED до DEGRADED. Сейчас эта опция ЕСТЬ. ЕСТЬ! И ты заткнёшься, наконец, а?
| | |
| |
| 6.118, Аноним (-), 17:45, 05/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Если три из четырёх копыт отброшены, то никакой fsck, ни scrub ни
> на каком RAID кроме mirror ничего тебе не пролечит,
Нормально реализованный fsck (как у ext-ов например) пролечит все что хоть минимально напоминает файловую систему, чем и хорош. Можно данные потом достать с порушенного диска как белый человек, а не хексэдитором выколупывать...
| | |
| |
| 7.119, iZEN (ok), 21:48, 05/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> Если три из четырёх копыт отброшены, то никакой fsck, ни scrub ни
>> на каком RAID кроме mirror ничего тебе не пролечит,
> Нормально реализованный fsck (как у ext-ов например) пролечит все что хоть минимально
> напоминает файловую систему, чем и хорош. Можно данные потом достать с
> порушенного диска как белый человек, а не хексэдитором выколупывать...
Ваш fsck аккуратно сложит всё найденное в /lost+found под ничего незначащими именами.
scrub же после завершения своей работы покажет список повреждённых файлов, которые восстановить не удастся, а пул станет отремонтированным. Так кто там будет лазить с hex-редактором по диску, определяя, какой файл в /lost+found откуда взялся, а? :))
| | |
| |
| |
| 9.122, iZEN (ok), 22:52, 05/03/2012 [^] [^^] [^^^] [ответить] | +/– | scrub выполняет проверку только занятого пространства fsck выполняет проверку в... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 1.123, iZEN (ok), 20:08, 03/08/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Btrfs всё - https://www.opennet.dev/opennews/art.shtml?num=46955
///---
В категорию устаревших (deprecated) переведена поддержка Btrfs и FedFS (Federated File System). Файловая система Btrfs ранее позиционировались в дистрибутиве RHEL 7 как экспериментальная возможность (Technology Preview), не рекомендованная к применению в промышленных решениях. Компания Red Hat приняла решение не выводить Btrfs в разряд полностью поддерживаемых в RHEL технологий и поддержка данной ФС будет прекращена в будущем значительном выпуске RHEL 8. Что касается RHEL 7.4, то в Btrfs продолжен перенос некоторых изменений из upstream. В дальнейшем, пользователи следующих выпусков ветки RHEL 7 смогут продолжить использовать Btrfs, но изменения больше переноситься не будут.
---///
| | |
|
