Пользователи дистрибутива Gentoo обратили внимание (https://bugs.gentoo.org/638206) на регрессивное изменение в ядре Linux 4.14 (https://www.opennet.me/opennews/art.shtml?num=47513), которое может привести к повреждению содержимого файловой системы при использовании механизма BCache (https://www.opennet.me/opennews/art.shtml?num=35849) для кэширования доступа к медленным жестким дискам на быстрых SSD-накопителях. Исправление уже предложено (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) для ядра Linux и будет включено в выпуск 4.14.2.
Суть проблемы в том, что в ядре 4.14 в системе блочного ввода/вывода (bio) для указания информации о разделах было представлено новое поле bi_partno, вместо того чтобы использовать уже применяемый метод кодирования сведений в поле bi_bdev в структуре bdev->bd_contains. Функция __bio_clone_fast была адаптирована для копирования информации о диске, но не корректно обрабатывала информацию о разделах на нём, что могло привести к повреждению содержимого при использовании BCache.
В зависимости от настроек проблема проявляется выдачей (https://www.spinics.net/lists/linux-bcache/msg05290.html) некорректных данных при чтении из раздела BСache, но также отмечаются и случаи невосстановимых повреждений базового раздела после его монтирования в составе BCache. Не исключено, что проблема может проявляться и для других блочных подсистем ядра, использующих вызов __bio_clone_fast.URL: https://news.ycombinator.com/item?id=15750029
Новость: http://www.opennet.me/opennews/art.shtml?num=47607
Торвальд не юзает BCache, Kent Overstreet набыдлoкoдил и протолкнул как бывший сотрудник гугла.
И причём здесь Кент? Он код отдал, попрощался и уже давно занимается разработкой BCacheFS. А BCache (как и большинство файловых систем в ядре кроме большой тройки) поддерживают мейнтейнеры VFS и сообщество.Не его вина, что эти мейнтейнеры приняли гору кривых патчей, который в процессе рефакторинга запороли некоторые файловые системы.
"Торвальд" писал в одном из первых rc, что зря они заранее объявили, что 4.14 будет lts. Из-за этого все постарались запихнуть в этот релиз как можно больше функционала, пожертвовав его качеством и ссылаясь на то, что "lts же, не замержим - придётся ждать следующего, так как солидные люди сидят на lts" и "lts же, давайте закоммитим, а поправим ПОТОМ".
> Торвальд не юзает BCache, Kent Overstreet набыдлoкoдил и протолкнул как бывший сотрудник
> гугла.торвальд не юзает линукс, его всё - миникс,
который он с**л и адаптировал для транспьютерных систем и вообще для скайнет
OpenZFS нужно было использовать там все уже из-коробки протестировано за многие годы.
CDDL and GPL legal incompatibility
Да плевать с высокой колокольни, ни кто не узнает и не проконтролирует. Бери и пользуйся.
github так и делает
И правильно делает, что способствует его процветанию. И плевать ему на рейтинги-писькомерки свободности от гну и Стулманоугодность.Берите с него пример, и ни кого не слушайте. Если софт доступен - можно его пользовать, а лицензии - дело сотое.
https://en.wikipedia.org/wiki/Tragedy_of_the_commons почитайте для общего развития
Вы как большинство копирастов считаете интеллектуальную собственность исчерпаемым ресурсом чтоли?
Трагедия общин о том, что если все пользуют общий ресурс по полной, то всем станет хуже.Тут же все скорее наоборот - вместо того, чтобы пользоваться готовым и развивать, переизобретают велосипеды в виде совместимого btrfs - ресурсы потрачены нерационально.
zfs же не блоб закрытый, а вполне себе под открытой лицензией код. Это проблема gpl, что она вирусная.
> Вы как большинство копирастов считаете интеллектуальную собственность исчерпаемым ресурсом
> чтоли?Боюсь, вы не поняли сути трагедии общин.
Если "все" положат болт на лицензии, то в конце концов пострадают тоже "все".
А вот это "науке неизвестно", к слову.
#>Если "все" положат болт на лицензии, то в конце концов пострадают тоже "все".
> А вот это "науке неизвестно", к слову.Как же-с!? Известно-с. До статута Анны же все, буквально все!, страдали не-имо-вер-но. Же. Потом пришёл всем копиразм-с -- вот и зажили же. ><WWW9>
эти уроды из оракакеля похоронили сначала солярис а потом и зфс
при этом развивают свою недофс под названием бтрфс, пародия блин.
Тебя посодюьЪ. А ты не воруй! (С) :)
> Да плевать с высокой колокольни, ни кто не узнает и не проконтролирует.
> Бери и пользуйся.И потестируй на себе, как оно там теряет или не теряет данные. Потому что крупняку подставляться неохота, разработчики ядра тоже этим не пользуются. Поэтому на себе и потестируете качество интеграции с тем или иным ядром. Можно в перервах подрабатывать манекеном для краштестов еще.
Кэширование на SSD - костыль. Толком ничего не ускоряется.
И SLC под кэш выйдет дороже, чем TLC нужного размера.
> И SLC под кэш выйдет дороже, чем TLC нужного размера.это если общий объем данных туда можно впихнуть...
а когда полка с терабайтами (в массиве), а часто изменяемых данных на десятки/сонтни гигабайт - кэш вполне решает задачи
ТЛС обойдется существенно дороже учитывая еще и циклы его замены (если в рэйдах)
https://geektimes.ru/post/271788/
в рэйдах еще и на контроллеры придется разорится (ибо несколько SSD - вполне канал уложат)
и еще особенность SSD рэйдов https://habrahabr.ru/company/webzilla/blog/227927/если коротко - кэш бюджетное решение для сценариев использования
> Кэширование на SSD - костыль. Толком ничего не ускоряется.При раздаче видео - не ускоряется, а при раздаче кучи мелких файлов (картинки, css, жабоскрипт) очень существенное ускорение.
В лине есть дисковый кэш, он кэширует чтение и использует всю свободную оперативную память. Если говорить про "кучи мелких файлов", то современный пк с 4-8 гб может закэшировать миллионы таких файлов. И для этого не нужно покупать и насиловать SLC SSD, ресурс которой всетаки ограничен. SSD используется именно для кэширования записи, т.к. информация не теряется при непредвиденном выключении питания.
кешировал, пока редхет чото в своём ядре не поломал
У меня что в лине, что в винде, к дисковому кэшу вообще никаких нареканий никогда не было. Кажется это одна из самых отточенных систем.
современный ПК это линукс с 64 гиббонами оперативки, в котором базовая система занимается анальными ограничениями от всяких замечательных личностей и маршрутизацией пары десятков под kvm машин живущих на zol/zfs. основная живёт с прокинутым внутрь железом. восстановление из снэпшота - миллисекунды и привет плохишам, которых нет. а больших систем ты не видел, мой юный друг.
ZFS весьма эффективно PCIe M.2 диски как кэш пула использует. Практически весь пул со скоростью данного SSD работает. На FREEBSD
зфс тормозной, l2arc забывает контент при перезагрузках, в отличии от bcache.root@blackfish:~# dd if=/dev/nvme0n1 of=/dev/null bs=64k count=65536
65536+0 records in
65536+0 records out
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 0,466574 s, 9,2 GB/s
"l2arc забывает контент при перезагрузках, в отличии от bcache." - оно и не надо никому. Кэш таскать через перезагрузки (facepalm). Перезагрузка она на то и перезагрузка чтобы переинициализировать кэши и т.п. Linuxоиды как обычно - изобретают велосипед с 10 запасными колесами и чтобы АВТОМАТИЧЕСКИ заменялись, вместо того чтобы посмотреть на более 60 летний опыт людей, которые ZFS спроектировали. Там это прошли давно и отказались. Так как вместо эффективности - "автоматическая замена колес" это дополнительный сложный механизм, эффективность которого, по сравнению с ручным гаечным ключем, на порядки меньше, а вот проблем все это доставляет гораздо больше. Так как сложный механизм тоже требует обслуги и квалификации. И в общем приходим к традиционному бреду в развитии Linux - ОБСЛУЖИВАНИИ ради ОБСЛУЖИВАНИЯ. Замкнутый круг.
вы сколько угодно можете таскасть морду лица туда-сюда демонстрируя "фасепальмы"
на тридцати терабайтах торрентов при более 450 активных раздач (а оно случайно а не линейно) вам нужно пройти в ванную комнату, помыть лицо, промыть глаза наконец. с мылом, возможно, детским. чтобы глазки не щипали.тут под боком три амс2300 по 200 тера каждый.
А где ты хостишься? Это особо укрепленный бункер, в здании абузоустойчивого хостинга? На случай визита копирасов :)
> А где ты хостишься? Это особо укрепленный бункер, в здании абузоустойчивого хостинга?
> На случай визита копирасов :)это особо укреплённый локалхост, в шахте 758 метров под землёй, собственная электростанция и три волокна наружу в lacp на шеститонник.
> "l2arc забывает контент при перезагрузках, в отличии от bcache." - оно и
> не надо никому. Кэш таскать через перезагрузки (facepalm)вы почитайте ту-ду и там в планах сделать l2arc "персистентным" внезапно мой юный друг.
А ноги откуда растут? Опять из стада Linux? Внезапно….
ноги растут из тела, как принято у нормальных, не альтернативных человеков.
> "l2arc забывает контент при перезагрузках, в отличии от bcache." - оно и
> не надо никому. Кэш таскать через перезагрузки (facepalm)."разогрев кэша" вам не знаком, мой юный друг.
Вообще-то, сейчас это молится: https://wiki.illumos.org/display/illumos/Persistent+L2ARC
> Вообще-то, сейчас это молится: https://wiki.illumos.org/display/illumos/Persistent+L2ARCво.
Зависит от сценария использования.
Я на рабочем компе использую LVM-cache для LV где расположены всякие 1С-ные базы.
Открытие баз и запись в них (в некоторых сценариях, например в конфигураторе) существенно ускоряется.
Если вырубить lvm-cache то сразу заметно замедление.
> Кэширование на SSD - костыль. Толком ничего не ускоряется.Внимание, альфачи хайлоада в треде!
Вот и результат релизов каждые 2 месяца.. не протестируешь ничего.
Зато релизы быстро пекутся.
Этот BCache для энтузиастов. В реальной работе его никто не использует, т.к. дорого и не эффективно. А все нужные вещи в ядре вполне достаточно тестируются.
> Этот BCache для энтузиастов. В реальной работе его никто не использует, т.к.
> дорого и не эффективно. А все нужные вещи в ядре вполне
> достаточно тестируются.Ну конечно. Что дорого и что неэффективно?
При нескольких терабайтах картинок - очень эффективно и не дорого. Гораздо дешевле, чем на SSD хранить.
У вас эти терабайты постоянно записываются или считываются? BCache используется для кэширования записи. Использовать его для кэширования чтения - абсурд. С этим вполне хорошо справляются небольшие объемы оперативки.
То ты больших объёмов не видел. Если у тебя мелкий сайтик - то что угодно справится, конечно. А теперь представь себе reddit или что-то вроде инстаграм - есть огромная куча контента, популярного - доли процента, но всё же RAM пихать - дороговато выйдет.
А всё и не надо пихать. Там сьюминутно нужно 2-5% контента. Оперативка покрывает 90% запросов чтения. Ну а остальное и hdd потянет.
чтение в память измененных данных как будет проходить? ;)
Кэш чтения зависит от кэша записи, в массе кейсов
Данные попадают в кэш как при чтении, так и при записи. Только что записанный файл будет в кэше.
Кэша записи в оперативке фактически не существует, т.к. по умолчанию для всех задач подразумевается требование незамедлительного сохранения данных.
> Кэша записи в оперативке фактически не существует, т.к. по умолчанию для всех
> задач подразумевается требование незамедлительного сохранения данных.где вас берут таких в огороде с капустой?
почему я наблюдаю дисковую активность спустя несколько секунд после копирования?
> Кэша записи в оперативке фактически не существует, т.к. по умолчанию для всех
> задач подразумевается требование незамедлительного сохранения данных.dirty cache [pages]:
https://kernelnewbies.org/Linux_2_6_32#head-72c3f91947738f1e...
> У вас эти терабайты постоянно записываются или считываются? BCache используется для кэширования
> записи. Использовать его для кэширования чтения - абсурд. С этим вполне
> хорошо справляются небольшие объемы оперативки.вы это своей бабушке рассказывайте
отдача торрентов, чисто чтение, 25% bcache.
ЧЕТВЕРТЬ, КАРЛ!!!.
> У вас эти терабайты постоянно записываются или считываются? BCache используется для кэширования
> записи. Использовать его для кэширования чтения - абсурд. С этим вполне
> хорошо справляются небольшие объемы оперативки.особо одарённые личности утверждают, не имея опыта bcache
Абсурд это ваше существование.
> Этот BCache для энтузиастов. В реальной работе его никто не использует, т.к.
> дорого и не эффективно. А все нужные вещи в ядре вполне
> достаточно тестируются.в ведре пространства много, можно сблевануть не вызывая проблем.
вы не имеете опыта ни с zfs (точнее zol) ни с bcache.
для меня это профессионально, и одно и другое используется многие годы.
доастало уже
> Этот BCache для энтузиастов. В реальной работе его никто не использует, т.к.
> дорого и не эффективно. А все нужные вещи в ядре вполне
> достаточно тестируются.Откуда вы только повылазили...
... а "ЫнтырпрайзЭ на гентах и арчиках страдает...
В арче кстати 4.14 еще в тестинг. Хочу посмотреть на человека держащего ынтырпрайз на тестинг
АлавердЫ! Хочу посмотреть на человека держащего ынтырпрайз на раче 8-)
> АлавердЫ! Хочу посмотреть на человека держащего ынтырпрайз на раче 8-)Антресольный или поддиванный ынтырпрайз cети 127.0.0.0/8?
> АлавердЫ! Хочу посмотреть на человека держащего ынтырпрайз на раче 8-)гламурно-кошерный ынтерпрайз делается не в каком то там каноникал, а на коленке.
затем испытывается пару месяцев на подопытных кроликах.
потом идёт в продакшн. испытано сотни раз в течении более 16 лет.
минимализм наше всё.
"интерпрайз" в работе, арч вылез как абортыш из CRUX, ядро последнее, считайте LFS поскольку многое руками сделано в обход разрабам. Под капотом шестьсот терабайт всякого хлама на zol. Работает уже лет 16, никаких нареканий.
>> было представлено новое поле bi_partno, вместо того чтобы использовать уже применяемый метод кодирования сведений в поле bi_bdev в структуре bdev->bd_containsа теперь смотрим на фикс
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stabl...
т.е. сделали подпорку для ненужного поля bi_partno, вместо того чтобы его выкосить и использовать уже существующий механизм
http://www.opennet.me/openforum/vsluhforumID3/112742.html#13
Да там все ядро таких подпорок. Херак, херак и в продакшн.
>но также отмечаются и случаи невосстановимых повреждений базового раздела после его монтирования в составе BCache.Очень надеюсь, что это будет случаться как можно чаще.
Может хоть у кого-то глаза откроются.
Понятно, почему Товальдс хамит и кроет матом. Потому что и сюда рукожопы дорвались.
> Понятно, почему Товальдс хамит и кроет матом. Потому что и сюда рукожопы
> дорвались.Тащит в свою блоатварь всё, что блестит, как ворона, заралы "богайств" битротят и благоухают, но виноваты те "дорвались", да.
>> Понятно, почему Товальдс хамит и кроет матом. Потому что и сюда рукожопы
>> дорвались.
> Тащит в свою блоатварь всё, что блестит, как ворона, заралы "богайств" битротят
> и благоухают, но виноваты те "дорвались", да.зачем было интель пускать
Ой, а можно мне ещё рассказать про bcache + samba?
Там тоже весело, вплоть до смерти диска на котором дышит самба.
> Ой, а можно мне ещё рассказать про bcache + samba?
> Там тоже весело, вплоть до смерти диска на котором дышит самба.криворучки, кривые настроечки и ага. ты размер блока какой указал? при создании бкаши.
или гента? или выебунта?