https://m.opennet.me/openforum/vsluhforumID3/110083.html Состоялся (https://plus.google.com/+RcloneOrg/posts/j2CVbmckGLJ) выпуск утилиты rclone 1.35 (http://rclone.org/), которая представляет собой аналог rsync, предназначенный для копирования и синхронизации данных между локальной системой и различными облачными хранилищами, такими как Google Drive, Amazon Drive, S3, Dropbox, Backblaze B2, One Drive, Swift, Hubic, Cloudfiles, Google Cloud Storage и Yandex Files. Код проекта написан на языке Go и распространяется (https://github.com/ncw/rclone/) под лицензией MIT.<br><br><br>Основные особенности:<br><br><br>- Контроль целостности передаваемых данных при помощи хэшей MD5/SHA1;<br>- Сохранение исходного времени модификации и создания файлов;<br>- Поддержка режима частичной синхронизации, при которой копируются только изменившихся в файле данные;<br>- Режим копирования на целевую систему новых и изменившихся файлов;<br>- Режим синхронизации для обеспечения идентичного состояния двух директорий на разных системах;<br>- Режим проверки для сверки контрольных сумм;<br>- Возможность синхрон https://m.opennet.me/openforum/vsluhforumID3/110083.html#85 Fri, 13 Jan 2017 13:57:36 GMT &gt; Если ZFS пулл собран админом на нескольких дисках, например в режиме raidz,<br><br>...то мы вспоминаем что бэкапы нужны раз в сто лет а хоанилка начинает удорожаться. <br> <br>&gt; BAD SECTOR абсолютно по барабану. Останавливаем сбойный диск, заменяем на новый, <br>&gt; даем ZFS команду принять замену. Все! <br><br>Это в теории. А на практике случаи разные бывают. Вон на лисяре описан случай когда файлуха просто не смонтировалась. Хорошо если ты джеди и можешь вручную, хексэдитором, всех нае..., но это наверное не про обычного оператора бэкапов.<br><br>&gt; В зависимости от размера диска и загруженности пулла система придет в норму<br>&gt; максимум через сутки ))) <br><br>А в течение этих суток на остальные диски будет повышенная нагрузка и спасибо если ничего новенького в результате не помрет. Ну и в целом супернадежные многодисковые хранилки стоят денег а проблему например пожара в серверной или иных катастрофических отказов - не решают.<br><br>&gt; Куда страшнее "умные" дисковые контроллеры!!!<br><br>Вот это да - если уникум подохнет и у людей не было за https://m.opennet.me/openforum/vsluhforumID3/110083.html#84 Fri, 13 Jan 2017 13:36:46 GMT &gt; Очень интересно общаться с человеком, которому пишешь про схему 3-2-1 (которая подразумевает <br>&gt; два бэкапа на другие машины, <br><br>Хм, я как-то пропустил этот момен.<br><br>&gt; Ты сразу напиши один раз, что ты тут продаёшь, маркетолух, <br><br>Да ничего я не продаю. Просто констатирую что полно коммерческих решений которые все это уже делают, без привязок к файлухе, с возможностью развернуть свой сервер бэкапа за какие-то минуты и как раз нарулить бэкапный план с раскидыванием на географиески разные сервера. <br><br>А ZFS тут ни в п..., ни в красну армию. Делать отдельно взятый сервер бэкапов сверхнадежным нафиг надо, бэкапы места занимают немеряно и удорожать хранилище под них - сомнительная радость. Вот географически раскидать - очень хорошая идея. А от zfs единственная польза разве что проверка чексум.<br> https://m.opennet.me/openforum/vsluhforumID3/110083.html#83 Fri, 13 Jan 2017 13:30:44 GMT &gt; От повреждения файла или чанка в диф. бэкапах спасает только полное его <br>&gt; копирование, что в описанном решении с ZFS, что в твоем "нормальном <br>&gt; бэкапном софте".<br><br>Просто нормальный бэкапный софт все это умеет вообще без приявзки к файлухе и каких либо допущений о меганадежных хранилках. Ну то-есть для хранения бэкапов не обязательно городить супернадежный (и поэтому архидорогой) стораж. Достаточно вменяемую схему бэкапов и хранение на нескольких разных серверах, в нескольких физических локациях. Например, на случай если какая там хранилка решит выгореть синим пламенем целиком.<br><br>&gt; С ZFS это тоже можно реализовать, простейший способ - <br>&gt; копировать снапшоты в другой пул раз в неделю, либо архивировать в тот же пул.<br><br>Оно как бы можно, но это как бы закат солнца вручную. А в тот же пул - чревато тем что у вас случится catastrophic failure в вашей мегахранилке который будет запроектной аварией для ZFS и вам вынесет все бэкапы одним махом. Что наверное не здорово. У упомянутых вендырей нарулить бэкап на н https://m.opennet.me/openforum/vsluhforumID3/110083.html#82 Fri, 13 Jan 2017 05:16:08 GMT &gt; OK, я не верно сказал. LTO может вынести и функции целиком.<br><br>Это его нормальное состояние, я бы сказал.<br><br>&gt; Просто затраты (как CPU, так и RAM) на это будут гораздо большими, <br>&gt; чем с -ffunction-sections -fdata-sections + -Wl,--gc-sections. <br><br>А это другой вопрос. В свежих gcc, кстати, LTO основательно разогнали а потребление RAM убавили.<br><br>&gt; Точно не помню, сколько памяти надо для сборки FF с LTO, но за 4GB перевалило давно.<br><br>Вот это не знаю, не пробовал такого монстра. На 5-меговой софтине на плюсах лопало около гига памяти, чтоли. Кстати LTO агрессивно оптимизировали по ресурсам в gcc 5.x/6.x, да и скорость компиляции прилично подтянули, особенно на уровнях с оптимизацией.<br><br>&gt; цель скорость исполнения - однозначно LTO, но бинарник из-за inline может <br>&gt; стать и больше.<br><br>В среднем по больнице результат таков что прога сдувается по размеру а скорость такая же или чуть лучше. Т.е. я бы больше радовался уменьщению кода.<br><br>&gt; Ну на AVR я как раз -fwhole-program и использую. Она несовместима с LTO - исп https://m.opennet.me/openforum/vsluhforumID3/110083.html#81 Tue, 10 Jan 2017 22:09:17 GMT &gt;&gt; части функций, которые не используются.<br>&gt; Я проверял на разном софте.<br>&gt; 1) Упомянутый мной tweetnacl-lite, с которым я развлекаюсь засовывая его в cortex-M. <br>&gt; Если с LTO собрать, но нигде не вызвать, LTO его выносит <br>&gt; целиком.<br><br>OK, я не верно сказал. LTO может вынести и функции целиком. Просто затраты (как CPU, так и RAM) на это будут гораздо большими, чем с -ffunction-sections -fdata-sections + -Wl,--gc-sections. Точно не помню, сколько памяти надо для сборки FF с LTO, но за 4GB перевалило давно. Если цель уменьшить бинарник - то и gc-sections хватит. Если цель скорость исполнения - однозначно LTO, но бинарник из-за inline может стать и больше.<br><br>&gt; Как по мне так там с -flto -fwhole-program (whole-program имеет некие особенности, <br>&gt; ахтунг) dead code вырубается очень даже.<br><br>Ну на AVR я как раз -fwhole-program и использую. Она несовместима с LTO - используется вместо LTO.<br><br>&gt;&gt; Зависит от того какой код. Допустим 10% уходило на вызов + сохранение <br>&gt;&gt; + восстановление регистров. Мы инлайним эту ф https://m.opennet.me/openforum/vsluhforumID3/110083.html#80 Tue, 10 Jan 2017 17:50:52 GMT &gt; части функций, которые не используются.<br><br>Я проверял на разном софте.<br>1) Упомянутый мной tweetnacl-lite, с которым я развлекаюсь засовывая его в cortex-M. Если с LTO собрать, но нигде не вызвать, LTO его выносит целиком. Ну то-есть от него ничего не остается. Если другого кода не было - я получаю пустой бинарь, состоящий из дефолтных vectors. Как еще эффективнее код выносить я даже и не знаю :)<br><br>2) В большом сложном бинаре на плюсах LTO вырубил примерно четверть кода.<br><br>Как по мне так там с -flto -fwhole-program (whole-program имеет некие особенности, ахтунг) dead code вырубается очень даже.<br><br>&gt; Больше всего выбрасывает -ffunction-sections -fdata-sections + -Wl,--gc-sections так <br>&gt; как выкидывает неиспользуемые функции и данные целиком.<br><br>Упомянутое вроде бы вырубает неиспользуемые функции просто в ноль. И особенности особенностями, а в типовых случаях не вижу никаих проблем. Законы мерфи не отменяли.<br><br>&gt; Зависит от того какой код. Допустим 10% уходило на вызов + сохранение <br>&gt; + восстановление регис https://m.opennet.me/openforum/vsluhforumID3/110083.html#76 Mon, 09 Jan 2017 15:31:29 GMT Что за BSD без libc? :)<br> https://m.opennet.me/openforum/vsluhforumID3/110083.html#75 Mon, 09 Jan 2017 08:43:43 GMT &gt; Можно сжатие включить и дедупликацию без бубнов.<br><br>Здесь чуть поправлю, т.к. сам эксплуатирую подобное на несколько ТБ.<br>Онлайн-дедупликацию zfs трогать не надо, не имея "бесконечных" cpu&#124;ram. Если таки нужен дедуп, используйте встроенное в rsync (rc4, увы, вероятность коллизии так себе).<br>+ "нюанс" rsync: он сначала на источнике/приёмнике делает *всю* карту КС для переливаемого файла. (Это "стреляет" начиная с десятков ГБ на файл.) Т.е. запасайтесь памятью, уже&#769; для rsync. Мельче блоки &#8212; больше памяти&#8230;<br> https://m.opennet.me/openforum/vsluhforumID3/110083.html#74 Fri, 06 Jan 2017 19:06:56 GMT Чувак, ты не прав )))<br>Если ZFS пулл собран админом на нескольких дисках, например в режиме raidz, BAD SECTOR абсолютно по барабану. Останавливаем сбойный диск, заменяем на новый, даем ZFS команду принять замену. Все! В зависимости от размера диска и загруженности пулла система придет в норму максимум через сутки )))<br>Куда страшнее "умные" дисковые контроллеры!!!<br>Если накроется такой контроллер, пулл восстановить на новом контроллере, с вероятностью 99% не удастся. Для ZFS чем тупее контроллер, тем лучше.<br>