Внезапно, это только одна капля в море.
Включайте в голове всю картину мира блин.
Потом, создают контент как и записывают в основном без ECC памяти, да и ECC теперь то же стал под вопросом надежности. В итоге если вам интересно и хотите лучше узнать материал, я думаю вы его сами найдете и изучите.
Вы так и не поняли масштабы трагедии и что пытаюсь донести.
Если идти дальше, то это проблема сразу всех и инженеров и программистов и прослойки между креслом и пк.
Вот почитайте на досуге пепер про хакинг DNS без уязвимости.
Потом рекомендую найти такой пепер по исследованию открытых ФС, пепер про надежность данных в самой памяти, пепер исследование про работу роутеров и надежность доставки пакета в них (но опять там больше относится проблема к памяти) Как прочтете, можно будет начинать разговаривать про прослойку между ПК и креслом и чьи это проблемы. =:-P
Да я тут конечно нагнетаю и на кучу информации изменения одного байта, приносит пока мало проблем, но кто знает, что-там будет в будующим?
а кто даст гарантия, что crc(или что там будет) на данные у вас составлен на верные данные?
На самом деле вопрос не так прост, как кажется на первый взгляд.
>LTO-7 дает емкость в 6 Тб, 15
Вы решили поиграть в КО?
>Лента не дает 100% гарантии, что через 10 лет данные не побьются из-за каких-либо внешних воздействий — физических, электромагнитных, механического износа и пр.
А кто дает 100% гарантию?
Я вам скажу больше, что не кто не гарантирует, что вы данные записали правильно. При этом не важно куда.
Кто даст гарантию, что вы напечатали текст и редактор правильно сохранил его?
Кто даст гарантию, что при сохранении файла в памяти не изменились биты?
Ну и кто даст гарантию, что ФС у вас этот файл нормально сохранила?
Когда начинаешь читать такие пеперы или доклады, то волосы начинают шевелится во всех местах и шкала паранойи начинает зашкаливать. Относительно недавно этот вопрос поднимался, например про память. Когда сделали фейковые домены популярных ресурсов, которые отличались байтом. Статистика была забавна.
Или разбор полётов открытых ФС, когда находятся забавные ошибки, которые могут уничтожить все.
Теперь о лентах.
Так как я любитель лент, скажу, что если мы уберем параною, то данные вполне читаются.
Самое старое, что я считовал это касету DDS-1 1990 года. Ей уже стукнуло 26 лет, о каких 10 годах вы вообще тут вещаете?
Если брать LTO, там есть отдельные насители WROM, для более долгого хранения.
Поэтому я на текущий момент верю пленки.
Если брать CDROM, то и они живы. Если помните были с покрытием золота или серебра. В общем прочитать можно и все нормально, но вот тут действительно возникает другая проблема!
Мы все это прочитали и достали, а вот будет ли у нас чем открыть и на чем открыть эту информацию?
-a alignment-type, --align alignment-type
Set alignment for newly created partitions, valid alignment types are:
none Use the minimum alignment allowed by the disk type.
cylinder
Align partitions to cylinders.
minimal
Use minimum alignment as given by the disk topology information. This and the opt value will
use layout information provided by the disk to align the logical partition table addresses to
actual physical blocks on the disks. The min value is the minimum aligment needed to align
the partition properly to physical blocks, which avoids performance degradation.
optimal
Use optimum alignment as given by the disk topology information. This aligns to a multiple of
the physical block size in a way that guarantees optimal performance.
все зависит от настроек. Сжатие, дедупликация, пулы и предсказания.
минимально zfs требует 1Gb.
Если памяти мало то vfs.zfs.prefetch_disable=1 – отключение режима prefetch
vfs.zfs.arc_max — сколько будет кешироватся данных в пуле.
Если все по default и почитать гайд http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide
Станет понятно, что zfs старается забрать всю память кроме 1 Gb, но когда она потребуется он ее освободить. Я обычно прибиваю это гвоздями и отдаю не больше 4gb, остальное кеш на ssd.
Кешировать без SSD только в память бесмысленно, при перезагрузки вам надо опять будет прогревать кеш.
Я бы сказал по другому, у ZFS есть свои подводные камни.
Памяти он не особо требует много, если мы не начинаем заниматся с L2ARC итд.
Хотя если памяти очень много, я бы рекомендовал это сделать + SSD под еще один кеш.
в debian можно создать файл ответа и автоматизировать установку.
В итоге используя tftp, делалась установка по сети. День работы, стойка с proxmox готова без особого напряга.
bonding используется для отказоустойчивости + увелечение производительности сети (условно)
https://en.wikipedia.org/wiki/Link_aggregation
Пример, есть 4 сетевые карты eth0,1,2,3, делается единый интерфейс bond0, на него уже вешается vlan0,vlan1,vlan2 + n и уже vlan могут быть сбриджеванны с вирт машинами.
Надо понимать только про некий overhead по пакетам и насколько у вас стоят задачи так делать и насколько вам будет так удобно и нужно ли вообще. Я обычно делаю на автомате, если конечно позволяют мощности сети. Везде нужен здравый смысл.
на всякий случай, инструкция не моя.
с UEFI ситуацию так же можно вполне разрулить, но я уже насктолько привык все делать скриптами — что уже не использую стандартный установщик. Хотя тут наверно еще привычки с gentoo/archlinux, где по сути нет установщика.
я вот тут писал — http://unixforum.org/index.php?showtopic=136947
Там в конце примеры конфигов, правда они и сейчас наверно требует правок и дополнений.
Просто я еще использую объединение интерфейсов :)
а что там такого сложного с vlan?
Уже лет 8 использую bonding,vlan,bridge.
Основная сложность была в момент перехода proxmox на openvswitch, так как в debian свое видение конфигов.
Ну и народ еще забывает при использование HA, что кластер общается по мультикасту :)
Включайте в голове всю картину мира блин.
Потом, создают контент как и записывают в основном без ECC памяти, да и ECC теперь то же стал под вопросом надежности. В итоге если вам интересно и хотите лучше узнать материал, я думаю вы его сами найдете и изучите.
https://bitbucket.org/pcem_emulator/pcem/src
Отличается он хороший точностью эмулирования, для запуска например старых игр.
Понимаю, что интерес минимальный с вашей стороны, но очень хочется надеяться на проверку.
Если идти дальше, то это проблема сразу всех и инженеров и программистов и прослойки между креслом и пк.
Вот почитайте на досуге пепер про хакинг DNS без уязвимости.
https://media.blackhat.com/bh-us-11/Dinaburg/BH_US_11_Dinaburg_Bitsquatting_WP.pdf
Потом рекомендую найти такой пепер по исследованию открытых ФС, пепер про надежность данных в самой памяти, пепер исследование про работу роутеров и надежность доставки пакета в них (но опять там больше относится проблема к памяти) Как прочтете, можно будет начинать разговаривать про прослойку между ПК и креслом и чьи это проблемы. =:-P
Да я тут конечно нагнетаю и на кучу информации изменения одного байта, приносит пока мало проблем, но кто знает, что-там будет в будующим?
На самом деле вопрос не так прост, как кажется на первый взгляд.
Вы решили поиграть в КО?
>Лента не дает 100% гарантии, что через 10 лет данные не побьются из-за каких-либо внешних воздействий — физических, электромагнитных, механического износа и пр.
А кто дает 100% гарантию?
Я вам скажу больше, что не кто не гарантирует, что вы данные записали правильно. При этом не важно куда.
Кто даст гарантию, что вы напечатали текст и редактор правильно сохранил его?
Кто даст гарантию, что при сохранении файла в памяти не изменились биты?
Ну и кто даст гарантию, что ФС у вас этот файл нормально сохранила?
Когда начинаешь читать такие пеперы или доклады, то волосы начинают шевелится во всех местах и шкала паранойи начинает зашкаливать. Относительно недавно этот вопрос поднимался, например про память. Когда сделали фейковые домены популярных ресурсов, которые отличались байтом. Статистика была забавна.
Или разбор полётов открытых ФС, когда находятся забавные ошибки, которые могут уничтожить все.
Теперь о лентах.
Так как я любитель лент, скажу, что если мы уберем параною, то данные вполне читаются.
Самое старое, что я считовал это касету DDS-1 1990 года. Ей уже стукнуло 26 лет, о каких 10 годах вы вообще тут вещаете?
Если брать LTO, там есть отдельные насители WROM, для более долгого хранения.
Поэтому я на текущий момент верю пленки.
Если брать CDROM, то и они живы. Если помните были с покрытием золота или серебра. В общем прочитать можно и все нормально, но вот тут действительно возникает другая проблема!
Мы все это прочитали и достали, а вот будет ли у нас чем открыть и на чем открыть эту информацию?
емкость 6/15 GB
скорость 300/700 МБ/c
Срок хранения так уж точно не 10 лет и уж точно поболее cd/dvd и есть варианты WROM.
http://www.theregister.co.uk/2015/09/16/lto_has_15tb_gen_7_tape_format/
ну и скоро ждем lto8
Еще есть mdisc, но вот они под вопросом. Тут только время покажет, насколько долго.
-a alignment-type, --align alignment-type
Set alignment for newly created partitions, valid alignment types are:
none Use the minimum alignment allowed by the disk type.
cylinder
Align partitions to cylinders.
minimal
Use minimum alignment as given by the disk topology information. This and the opt value will
use layout information provided by the disk to align the logical partition table addresses to
actual physical blocks on the disks. The min value is the minimum aligment needed to align
the partition properly to physical blocks, which avoids performance degradation.
optimal
Use optimum alignment as given by the disk topology information. This aligns to a multiple of
the physical block size in a way that guarantees optimal performance.
минимально zfs требует 1Gb.
Если памяти мало то vfs.zfs.prefetch_disable=1 – отключение режима prefetch
vfs.zfs.arc_max — сколько будет кешироватся данных в пуле.
Если все по default и почитать гайд http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide
Станет понятно, что zfs старается забрать всю память кроме 1 Gb, но когда она потребуется он ее освободить. Я обычно прибиваю это гвоздями и отдаю не больше 4gb, остальное кеш на ssd.
Кешировать без SSD только в память бесмысленно, при перезагрузки вам надо опять будет прогревать кеш.
Мне кажется нужно держать Backup, не? :)
Хотя в общем мысль конечно ясно.
Памяти он не особо требует много, если мы не начинаем заниматся с L2ARC итд.
Хотя если памяти очень много, я бы рекомендовал это сделать + SSD под еще один кеш.
В Eoip уже была дабавленна поддержка ipsec.
Пример:
/interface eoip add comment=«To SkyNet» name=«To SkyNet EoIP» remote-address=2.2.2.2 tunnel-id=0 ipsec-secret=jfv0wev9rg356bg1
Хотя тот же meshbird и tinc намного проще в разы, но под mikrotik мы их не увидем.
В итоге используя tftp, делалась установка по сети. День работы, стойка с proxmox готова без особого напряга.
https://en.wikipedia.org/wiki/Link_aggregation
Пример, есть 4 сетевые карты eth0,1,2,3, делается единый интерфейс bond0, на него уже вешается vlan0,vlan1,vlan2 + n и уже vlan могут быть сбриджеванны с вирт машинами.
Надо понимать только про некий overhead по пакетам и насколько у вас стоят задачи так делать и насколько вам будет так удобно и нужно ли вообще. Я обычно делаю на автомате, если конечно позволяют мощности сети. Везде нужен здравый смысл.
с UEFI ситуацию так же можно вполне разрулить, но я уже насктолько привык все делать скриптами — что уже не использую стандартный установщик. Хотя тут наверно еще привычки с gentoo/archlinux, где по сути нет установщика.
Там в конце примеры конфигов, правда они и сейчас наверно требует правок и дополнений.
Просто я еще использую объединение интерфейсов :)
https://habrahabr.ru/post/272249/
Уже лет 8 использую bonding,vlan,bridge.
Основная сложность была в момент перехода proxmox на openvswitch, так как в debian свое видение конфигов.
Ну и народ еще забывает при использование HA, что кластер общается по мультикасту :)