Re: [DONE] wml://{events/2012/0707-rmll.wml}
On 17-07-21 19:13, Lev Lamberov wrote: > --- english/events/2012/0707-rmll.wml 2014-04-30 13:42:33.0 +0600 > +++ russian/events/2012/0707-rmll.wml 2017-07-21 19:13:04.362638224 +0500 > @@ -1,43 +1,44 @@ > -2012 RMLL is a free (as a beer and as a speech) and non commercial > -conference with talks, workshops and round tables about Free Software and > -its uses. The RMLL goal is to provide a place for exchange between Free > -Software developers, users and stakeholders. > +2012 RMLL бесплатная и свободная (и как пиво, и как слово) > некоммерческая > +конференция с докладами, семинарами и круглыми столами о Свободном ПО > +и его использовании. Цель RMLL состоит в том, чтобы предоставить место для > обмена между > +разработчиками Свободного ПО, пользователями и заинтересованных лиц. может лучше написать "место для общения разработчиков Свободного ПО, пользователей и прочих заинтересованных лиц"? -- Best regards, Andrey Skvortsov signature.asc Description: PGP signature
Re: [DONE] wml://events/2004/1{227-21c3,030-plgiessen}.wml
On 17-02-10 18:13, Lev Lamberov wrote: > --- english/events/2004/1227-21c3.wml 2005-01-04 23:01:45.0 +0500 > +++ russian/events/2004/1227-21c3.wml 2017-02-10 18:06:06.426158266 +0500 > @@ -1,26 +1,27 @@ > +#use wml::debian::translation-check translation="1.2" maintainer="Lev > Lamberov" > 21c3 > 2004 > Chaos Communications Congress > -Berlin, Germany > +Берлин, Германия > 2004-12-27 > 2004-12-29 > http://www.ccc.de/congress/ > -mailto:n...@ngolde.de>Nico Golde > +mailto:n...@ngolde.de>Нико Голде > ... > > -The Debian project will maintain a booth in the hackcenter together > -with Skolelinux. > +Проект Debian будет представлен на стенде в hackcenter вместе > +с Skolelinux. сО Исправил. -- Best regards, Andrey Skvortsov signature.asc Description: PGP signature
[DONE] wml://{security/2018/dsa-4091.wml}
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - --- english/security/2018/dsa-4091.wml2018-01-19 01:32:36.0 +0500 +++ russian/security/2018/dsa-4091.wml 2018-01-19 11:44:35.750947753 +0500 @@ -1,10 +1,10 @@ - -security update +#use wml::debian::translation-check translation="1.1" maintainer="Lev Lamberov" +обновление безопаÑноÑÑи - -Several issues have been discovered in the MySQL database server. The - -vulnerabilities are addressed by upgrading MySQL to the new upstream - -version 5.5.59, which includes additional changes. Please see the MySQL - -5.5 Release Notes and Oracle's Critical Patch Update advisory for - -further details: +Ð ÑеÑвеÑе баз даннÑÑ MySQL бÑло обнаÑÑжено неÑколÑко пÑоблем. УÑзвимоÑÑи +иÑпÑÐ°Ð²Ð»ÐµÐ½Ñ Ð¿ÑÑÑм Ð¾Ð±Ð½Ð¾Ð²Ð»ÐµÐ½Ð¸Ñ MySQL до новой веÑÑии из оÑновной веÑки ÑазÑабоÑки, +5.5.59, коÑоÑÐ°Ñ Ð²ÐºÐ»ÑÑÐ°ÐµÑ Ð² ÑÐµÐ±Ñ ÑÑд дополниÑелÑнÑÑ Ð¸Ð·Ð¼ÐµÐ½ÐµÐ½Ð¸Ð¹. Ðа подÑобноÑÑÑми обÑаÑайÑеÑÑ Ðº +инÑоÑмаÑии о вÑпÑÑке MySQL 5.5 и ÑекомендаÑии Oracle Critical Patch Update: https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-59.html;>\ @@ -13,14 +13,15 @@ http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html - -For the oldstable distribution (jessie), these problems have been fixed - -in version 5.5.59-0+deb8u1. +РпÑедÑдÑÑем ÑÑабилÑном вÑпÑÑке (jessie) ÑÑи пÑÐ¾Ð±Ð»ÐµÐ¼Ñ Ð±Ñли иÑпÑÐ°Ð²Ð»ÐµÐ½Ñ +в веÑÑии 5.5.59-0+deb8u1. - -We recommend that you upgrade your mysql-5.5 packages. +РекомендÑеÑÑÑ Ð¾Ð±Ð½Ð¾Ð²Ð¸ÑÑ Ð¿Ð°ÐºÐµÑÑ mysql-5.5. - -For the detailed security status of mysql-5.5 please refer to its - -security tracker page at: - -https://security-tracker.debian.org/tracker/mysql-5.5;>https://security-tracker.debian.org/tracker/mysql-5.5 +С подÑобнÑм ÑÑаÑÑÑом поддеÑжки безопаÑноÑÑи mysql-5.5 можно ознакомиÑÑÑÑ Ð½Ð° +ÑооÑвеÑÑÑвÑÑÑей ÑÑÑаниÑе оÑÑÐ»ÐµÐ¶Ð¸Ð²Ð°Ð½Ð¸Ñ Ð±ÐµÐ·Ð¾Ð¿Ð°ÑноÑÑи по адÑеÑÑ +https://security-tracker.debian.org/tracker/mysql-5.5;>\ +https://security-tracker.debian.org/tracker/mysql-5.5 # do not modify the following line -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE3mumcdV9mwCc9oZQXudu4gIW0qUFAlphk9gACgkQXudu4gIW 0qXy9w/9FqhCINDooKYTbRKp+kfJ15slZ4cVUWcOPMxyZge0ad6e3gpIuKL7rlsO 4QlKwnSSWTL+Y8pwCXjkayXtnG1iM+AC4qs63U7juiIeoKGSE8tedZtq5hl4wpDv 0NPctCnXUi/999Bf96JvyPG6/MRtbS3KwOLoNaiCgk5lvzg2sSS6LfAmwEyc61uW 3hEl9qzPrdLoc3csr0lRH+F8D+Uq9b/QtufMrGbebH9ocFzWnfFscaUPrWbN++ZY UnugQxjpIID/0iSn+fPhetZagVlmTeGspyMFso8KDJlzMLndl/tr1qxZhqdehA+1 e5cb2QIOpAEGStruZdBs1zp5d8lZWA3Poak0hfA7FW8KT2TMlh+HAf9OsS/TDhIk 6YqXLkVA97TXSe2Xe7bdhrteRj0L75bZcWXdetJSlmnIr66Iv4MvFdvMkQF12wPP N5rnVj0sNJ2Hhsl8Zf7RmWAROt2WHalSzRUXiMWoi+3AbegnphVuIapQkF0aofH6 G71/z3+ZVn6S5tfNgXbubNJ8NGQdT0nj/aOZUpgACpYrvfLYDMRKqGKn8c6hSVPY K2NoGvWhg1fw+lchTQr7BX1RhczYWiiuT43ITiuItvf/ApLWqtsN/DFYHbP9CorY YpBjzjOGRt1rzDnesiZglUTx8Fpfs7rcisFGwGNWNugO2BtFDrI= =WmRn -END PGP SIGNATURE-
Re: Снова о ZFS
*** Sergey Matveev [2018-01-16 00:15]: >https://blogs.oracle.com/darren/zfs-encryption-what-is-on-disk >Не знаю поменялось ли это в ZFS-е, но там говорят что L2ARC недоступен >для использования зашифрованным dataset-ам. Статья устарела. В https://youtu.be/frnLiXclAMo где точно актуальный разработчик они L2ARC уже шифруют. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
18.01.2018 22:02, Sergey Matveev пишет: > *** artiom [2018-01-18 21:53]: >> А что там за проблема с тем, что зеркало будет обеспечивать GEOM, была? > > Ну как минимум зачем это делать когда ZFS это тоже может? Во-первых, > меньше на одну прослойку из gmirror (или что там). Во-вторых, ZFS сам > это всё будет подхватывать. В-третьих, resilvering зеркала в ZFS, если > оно не сильно забито, существенно быстрее происходит чем обычного > RAID-а. Обычный RAID понятия не имеет какие данные актуальны на каком > диске -- он по сути делает последовательное полное чтение с одного диска > и запись на другой. А ZFS, увидев что диск был частью зеркала, найдёт > его последние актуальные данные и ссинхронизирует только diff. Если диск > не был в зеркале, то зальёт на него только полезную нагрузку > (терабайтный pool заполнен на 50 гигабайт? только эти 50 GB и будут > записаны на зеркало). В-четвёртых, если данные испортились на каком-либо > из дисков (ну ошибки, сыпется что-то), то из-за контрольных сумм точно > известно где данные корректные и он их восстановит на втором > (self-healing типа). > Стойте, вопрос-то в другом был. С пулом всё и так ясно (кроме шифрования). Вопрос был про служебные и системные носители. Короче, позже проработаю схему и опишу. Как-то непросто получается.
Re: Снова о ZFS
*** artiom [2018-01-18 21:53]: >А что там за проблема с тем, что зеркало будет обеспечивать GEOM, была? Ну как минимум зачем это делать когда ZFS это тоже может? Во-первых, меньше на одну прослойку из gmirror (или что там). Во-вторых, ZFS сам это всё будет подхватывать. В-третьих, resilvering зеркала в ZFS, если оно не сильно забито, существенно быстрее происходит чем обычного RAID-а. Обычный RAID понятия не имеет какие данные актуальны на каком диске -- он по сути делает последовательное полное чтение с одного диска и запись на другой. А ZFS, увидев что диск был частью зеркала, найдёт его последние актуальные данные и ссинхронизирует только diff. Если диск не был в зеркале, то зальёт на него только полезную нагрузку (терабайтный pool заполнен на 50 гигабайт? только эти 50 GB и будут записаны на зеркало). В-четвёртых, если данные испортились на каком-либо из дисков (ну ошибки, сыпется что-то), то из-за контрольных сумм точно известно где данные корректные и он их восстановит на втором (self-healing типа). -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
Хотя, вроде не так всё плохо. Взял две SSD на 256 ГБ (меньше не было): - Samsung 850 PRO (http://www.samsung.com/semiconductor/minisite/ssd/product/consumer/850pro/) - Micron MTFDDAK256TBN-1AR1ZABYY (https://market.yandex.ru/product--micron-mtfddak256tbn-1ar1zabyy/1721921626) Micron - TLC 3D, Samsung Pro - некий 3D V-NAND (хотя, есть подозрение, что это тоже самое). Ну и под L2ARC остаётся Samsung Evo. Сильно плохо? 16.01.2018 14:43, Dmitry Kulagin пишет: > >>> Это, кстати, очень странное замечание, я думал, что мы уже давно живем >>> во времена SATA-3 и всеобщей поддержки "WRITE BARRIERS" (ну за >>> исключением счетного числа сломанных дисков), так что энергонезависимый >>> кеш на запись для программного рейда давно не нужен... >>> >> Так здесь не про рэйд, как таковой, а про SSD пользовательского сегмента. >> > Так и я говорю про диски вообще, сейчас в любом накопителе хоть ССД > хоть НЖМД есть кешь память и она, что характерно, работает в режиме кеш на > запись по умолчанию, в режим только кеш на чтение она может переводиться > только > в аппаратных рейд контроллерах, потому как остальным ОС это не надо, > они пользуются командами сброса кеша в энергонезависимую память > для коммита транзакций. Кстати, поэтому не стоит покупать TLC SSD > диски для ZIL, на них этот коммит относительно долгий, а запись ZIL - > это непрерывный коммит, и кеш в такой ситуации не в состоянии > что-либо ускорить. А потери данных при перебое питания, которые > обсуждаются по ссылке будут всегда, вопрос только в том, что при > неадекватной > поддержке "WRITE BARRIERS" в firmware накопителей, Вам после каждого > перебоя > питания придется делать проверку файловой системы. > И фича сброса кеш памяти она, насколько я помню, не фича пользовательского > и корпоративного, или ССД и НЖМД сегмента, - это часть спецификации SATA-2 > (ну и SATA-3 и SAS, который вроде это изначально поддерживал еще со > времен SCSI) > и ее должны поддерживать все продающиеся сейчас накопители. > Насчет NVMe SSD не уверен, но думаю там должен быть аналог... >
Re: Снова о ZFS
> >>> Это, кстати, очень странное замечание, я думал, что мы уже давно живем >>> во времена SATA-3 и всеобщей поддержки "WRITE BARRIERS" (ну за >>> исключением счетного числа сломанных дисков), так что энергонезависимый >>> кеш на запись для программного рейда давно не нужен... >>> >> Так здесь не про рэйд, как таковой, а про SSD пользовательского сегмента. >> > Так и я говорю про диски вообще, сейчас в любом накопителе хоть ССД > хоть НЖМД есть кешь память и она, что характерно, работает в режиме кеш на > запись по умолчанию, в режим только кеш на чтение она может переводиться > только > в аппаратных рейд контроллерах, потому как остальным ОС это не надо, > они пользуются командами сброса кеша в энергонезависимую память > для коммита транзакций. Кстати, поэтому не стоит покупать TLC SSD > диски для ZIL, на них этот коммит относительно долгий, а запись ZIL - > это непрерывный коммит, и кеш в такой ситуации не в состоянии > что-либо ускорить. Блин, я похоже, херню сделал: спрашивал сегодня SLC/TLC вместо MLC (почему-то из этого коммента всё наоборот запомнилось).
Re: Снова о ZFS
16.01.2018 11:25, Sergey Matveev пишет: > *** artiom [2018-01-16 08:37]: >> - Либо я использую ZFS шифрование и теряю L2ARC (т.е. часть >> производительности). >> - Либо я использую Gely, усложняю систему и теряю часть возможностей и >> производительности ZFS. > > Ну насчёт заметной потери (чтобы об этом можно было думать) > производительности не уверен, ну а так да -- всё верно. > >> - Докупаю 2x100 Гб (достаточно 50 Гб или не стоит жадничать?) в зеркало. >> - На них делаю два раздела поверх gely: OS и ZIL. >> - SSD на 250 Гб отвожу под L2ARC (корзина на 2.5" забита, там три диска >> всего). >> - На SAS делаю Gely слой (предполагается, что все диско-специфичные >> ioctl будут проброшены вниз, но так ли это?). >> - Организую из 4-х SAS ZRAID1 (достаточно ли 1, а не 2?). > > Раз ZIL в зеркале, то вопрос надёжности снят. > > По поводу ioctl ничего не могу сказать, не задавался этим вопросом. > > RAIDZ какого уровня это tradeoff между кол-ом дисков сколько могут > вылететь, IOPS-ами, потерянным местом -- можно и 1, можно и 2. В > домашних условиях сервер же будет под "присмотром" -- поэтому вылет > диска будет обнаружен во вменяемое время и заменён для resilver-а. > > Не забыть что и ZIL и L2ARC разделы тоже надо поверх GELI сделать. Я > кстати L2ARC делаю поверх раздела зашифрованного одноразовым ключом > (geli onetime gpt/SSDCACHE ; zpool add storage cache gpt/SSDCACHE.eli): > после перезагрузки он конечно всё "потеряет", но зато ключи нигде не > надо хранить и загружать. > А что там за проблема с тем, что зеркало будет обеспечивать GEOM, была?
Re: тормоза ZFS
On 01/18/18 12:37, Sergey Matveev wrote: > вытесняют. ZFS может тупить например на секунды, допустим десятки секунд > -- сбрасывая буферы TXG на диски, но тут нет речи о минутах. Мне кажется > что это кто-то сторонний что-то начинает делать. Спасибо. Буду очень внимательно думать в эту сторону. Собственно, то, что это проделки ZFS, я предположил из-за того, что в такие моменты в iotop лидируют именно его процессы (хотя и не только они, но остальные каждый раз разные, а они всегда), о чем забыл упомянуть сразу. Тем не менее, раз такое поведение только у меня, значит, буду искать.
Re: тормоза ZFS
*** Alex Kicelew [2018-01-17 23:13]: >Поэтому может кто-нибудь (возможно, Sergey Matveev:) >знает, можно ли как-нибудь понять, за каким чертом он минут 5-15 читает >диск. Ух, даже не знаю что тут сказать. Вообще не могу предположить что именно ZFS мог бы делать. В фоне на долго ZFS обычно может делать только три вещи, как правило: scrub, resilver и destroy (когда async_destroy включен). На чтение из них только scrub работает. Но ARC сам по себе не будет просто так брать и освобождаться -- аналогично кэшу обычной ФС (cached поле в top/free). ARC уменьшиться в размерах только если какое-то приложение хочет памяти больше чем осталось -- тогда его вытесняют. ZFS может тупить например на секунды, допустим десятки секунд -- сбрасывая буферы TXG на диски, но тут нет речи о минутах. Мне кажется что это кто-то сторонний что-то начинает делать. Я не мало работал на системах с 4, 8 и 16 GB памяти и везде с HDD. 4 GB отличаются только тем, что по-умолчанию отключен read prefetch (но он ничего не может сделать чтобы система на минуты уходила "тупить"). Нагрузки были самые разные: и sequential read/write больших файлов и PostgreSQL с десятками GB БД и MongoDB которые упирались в IOPS диска. Но везде FreeBSD/HardenedBSD. Так что может быть это какие-то косяки в Linux реализации? Хотя коллега с GNU/Linux говорит что у него на 4 GB с HDD ни разу ничего похожего на ваше поведение не встречалось. Но мне кажется что это не в ZFS дело, раз размер ARC уменьшается -- его значит кто-то другой вытесняет. Можно попробовать например кэшировать только метаинформацию в ARC, возможно только для заданных dataset-ов, выставив zfs set primarycache=metadata. Не исключено что data регулярно вытесняет metadata и диск вынужден снова и снова лезть за ней на диск. Но это мысли в слух. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
