Home

70 километров марш на свободата се придвижва към столицата Отава. 29-ти януари в Канада ще бъде празник.

Хората са се вдигнали въпреки, че температурите в момента там падат до около -30 . Канада е потънала в мракобесен режим. Премиерът им Трюдо е един от най-наглите лакеи на задкулисието.

Желая им свобода !

Update(2022-01-30 02:38:03): Ето защо Ковид от силно опасно заболяване изведнъж стана нормален гpип.
След две години терор хората разбраха истината и казват СТИГА !!!

150 000 камиона са блокирали столицата на Канада.
Силно се надявам "тия маргинали" да успеят да изритат този боклук, който им е назначен за премиер и след като си позволи да ги обижда се скри в миша дупка с лъжата, че е бил кoнтaктeн.

Защото целият свят има нужда от прочистване.
Не само Канада!

Update (2022-01-30 02:45):
Според официални източници, министър-председателят Джъстин Трюдо и семейството му са напуснали Отава и са отведени на неизвестно сигурно място. След като мишата дупка с табелката COVID-19 отпред не успя да го скрие.

Update2 (2022-01-31 13:47):
Ако сте имали съмнения как ще бъдат отразени протестите в Канада ..

Update3 (2022-02-04 18:58):
Информационното затъмнение за случващото се в Канада продължава. Всички контролирани медии са в кюпа. ФБ банват организаторите, закриват им групите, крият постове по темата.

Отава е напълно блокирана от седмица. Гранични пунктове с щатите са блокирани. В САЩ и Европа набират сила движения вдъхновени от канадците.

Силно се надявам с тази предизвикана двугодишна криза да си вкарат мощен автогол. Все повече хора виждат фалша на медиите и разбират ролята на задкулисието, и ще участват в движенията за счупването на хомота.

Update4 (2022-02-10 03:07):

Две провинции разкарват мерките под натиска на протестиращите:

• https://globalnews.ca/news/8603220/alberta-covid-19-restrictions-lifted-update-february-8/
• https://nationalpost.com/news/canada/cp-newsalert-saskatchewan-ending-covid-19-passport-lifting-mask-requirement

Снимката е на автора на цитата - Езра Паунд.

В Канада готвят бунт срещу Koвид терора. Втори ден вече нито дума в централните емисии на Нова и bTV. Мейнстрийм медиите вече ги гледам само за да видя каква е пропагандата, с която се опитват да ни облъчат.

https://trud.bg/отпадна-задължителната-ваксинация-в-сащ/

Възможно ли е във всеки от нас да се съдържа енергия достатъчна да взриви хиляди планети като земята ?

Физици експериментиращи с технология за ядрен синтез ни показват точно това. Облъчват "камера" с големина около един кубичен милиметър и за 100 трилионни части от секундата се отделят 10 квадрилиона вата енергия, което казано на по-разбираем език се равнява на около 10% от слънчевата енергия, която попада върху земята за такъв кратък период.

Физиката работи с едва 4 вида фундаментални сили. Една от тях, наречена "силна ядрена" държи частиците във всеки атом заедно. И ако от толкова малка песъчинка може да се генерира такова колосално количество енергия си представете какво количество енергия е "заключено" във вас.

https://www.livescience.com/burning-hydrogen-plasma-record-breaking-fusion-experiment

Същата позиция, като тази на нашият протест против сертификатите, казана право в лицето на Урсула фон дер Лайън.

Да, същият грип, но видиш ли до сега беше МНОГО ОПАСЕН. Сега вече решаваме да не го наричаме така и щом ние така сме решили, значи вече не е опасен!

Ето ви мнение от организация на сестрите на "първа линия". Такова, каквото мейнстрийм медиите ще направят възможното да не чуете.

Интересно ми е дали всички вие, които се доверихте на и разпространявахте пропагандата през тези две години, ще си заровите главите дълбоко в пясъка сега, когато постепенно истината за свинщините започва да излиза отвсякъде. Или пък може би ще намерите някакво достойнство и ще се изправите и ще признате, че сте сгрешили и сте били подведени.

Ето един проблем, който вероятно ви засяга.

Това на графиката е как е нараствало количеството на записаните на диска ми за период от една година

Десктоп компютъра ми е това, не е някакъв сървър. Над 40 ТБ за година.

За да бъда по-точен ето ги числата:

Data Units Read:                    20,053,672 [10.2 TB]
Data Units Written:                 174,114,136 [89.1 TB]
Host Read Commands:                 249,982,008
Host Write Commands:                4,889,022,114
Power On Hours:                     13,343

, което е средно около 7 ГБ/час или 2МБ/сек за цялото време, през което е бил включен диска.

Машината не е да swapp-и тежко. С достатъчно памет е и си има предостатъчно свободна винаги.

Дискът е 500 ГБ NVMe (нещо като по-бърз SSD за незапознатите). Проблемът е, че този тип носители на данни има определено време на живот, което се определя именно от количеството данни, които се записват върху него. А за една година, се оказва, че диска е презаписан над 80 пъти.

Няма и тежки процеси, които да се забавляват да пишат толкова данни с равномерно темпо на този диск (примерно видеонаблюдение). Или поне не трябваше да има такива, но ето че графиката показа обратното.

Та като поразгледах - проблемът основно се дължи на Google Chrome, който пише като луд. И като не се ползва пак пише гадината.

Сега, не ме разбирайте погрешно. Не е като да не го ползвам. Имам постоянно отворени около 100-ина таба в 7-8 прозореца. Интеракцията ми с тях е доста ниска обаче. Стоят си отворени и ме чакат да ги погледна. Някои от тях от месеци - съответно дори не са заредени самите страници защото след последния рестарт не съм ги отварял изобщо, а просто съм възстановил сесията.

Има 3 отделни работни места(с техни си монитори, клавиатури, звук и т.н.) на компютъра, като жена ми работи от вкъщи и средногодишно прекарва значително повече време от мен пред него. Акси може да се каже, че рядко го ползва.

Но 40 ТБ ?! Скъпи Хром, ама моля те ..

Цъкнах тук там и естествено се оказва, че и други имат такъв проблем. Гледам, че има някакви заобиколки, като:

• слагане на тези части от файловите системи на магнитен диск
• или понеже са кешове и не е фатално да се загубят да са в паметта (tmpfs, /dev/shm под Linux)

, но по-скоро се надявах да попадна на настройка на браузера и да го откажа да ми скапва диска.

Не съм си свършил домашното още да проверя като хората за решение, но викам, че понеже и вас ви засяга, може някой да бъде така добър да се включи.

И не, не искам да сменям браузера.

Референции

• https://bugs.chromium.org/p/chromium/issues/detail?id=176727
• https://superuser.com/questions/1176408/chrome-writes-too-much-to-ssd

That's it.
I've had and unencrypted ZFS which I wanted to move to a new server.
I've preferred it to be encrypted on the new server.

I've had a few hiccups until I got it done, so I'm logging my experience.
Also for mine own further reference.

# zfs create -o encryption=on -o keyformat=passphrase -o keylocation=file:///path/to/zfs-key -o overlay=on rpool/lxc/prime

# zfs send --verbose --replicate --raw bkp_prime/bkp/prime/lxc@bkp-nightly-2022-01-21-0015 \
| \
zfs receive -Fuv -x mountpoint -x canmount -x overlay rpool/lxc/prime

cannot receive new filesystem stream: zfs receive -F cannot be used to destroy an encrypted filesystem or overwrite an unencrypted one with an encrypted one

# zfs send --verbose --replicate --raw bkp_prime/bkp/prime/lxc@bkp-nightly-2022-01-21-0015 \
| \
zfs receive -uv -x mountpoint -x canmount -x overlay -x encryption rpool/lxc/prime

cannot receive new filesystem stream: destination 'rpool/lxc/prime' exists

# zfs send --verbose --replicate --raw bkp_prime/bkp/prime/lxc@bkp-nightly-2022-01-21-0015 \
| \
zfs receive -Fuv -x mountpoint -x canmount -o encryption=on -o keyformat=passphrase -o keylocation=file:///path/to/zfs-key -o overlay=on rpool/lxc/prime

cannot receive new filesystem stream: zfs receive -F cannot be used to destroy an encrypted filesystem or overwrite an unencrypted one with an encrypted one

# zfs destroy -r rpool/lxc/prime

# zfs send --verbose --replicate --raw bkp_prime/bkp/prime/lxc@bkp-nightly-2022-01-21-0015 \
| \
zfs receive -Fuv -x mountpoint -x canmount -o encryption=on -o keyformat=passphrase -o keylocation=file:///path/to/zfs-key -o overlay=on rpool/lxc/prime

cannot receive new filesystem stream: incompatible embedded data stream feature with encrypted receive.

# zfs send --verbose --replicate -Lc bkp_prime/bkp/prime/lxc@bkp-nightly-2022-01-21-0015 \
| \
zfs receive -Fuv -x mountpoint -x canmount -o encryption=on -o keyformat=passphrase -o keylocation=file:///path/to/zfs-key -o overlay=on rpool/lxc/prime

cannot receive incremental stream: encryption property 'encryption' cannot be set for incremental streams.

### This time it almost worked as it received the first snapshot and created an FS :-)

# git clone https://github.com/rlaager/zfs-replicate.git

### Then I've recreated the encrypted ZFS and have tried

# ./zfs-replicate -n -r -v -u bkp_prime/bkp/prime/lxc rpool/lxc/prime
Checking for zfs send -c on destination: supported.
Checking for zfs send -e on destination: supported.
Checking for zfs send -L on destination: supported.
Checking for zfs send -t on destination: supported.
Comparing bkp_prime/bkp/prime/lxc -> rpool/lxc/prime
zfs destroy -r -n -v rpool/lxc/prime
would destroy rpool/lxc/prime

[...]

### Strangely it wanted to destroy the new encrypted ZFS
### I gave it a try anyway, this time without the dry-run option,
### and it destroyed it indeed, recreated it and started transferring.
### The newly created ZFS was not encrypted though.
### So I've checked its Python3 source and have tried to change "zfs destroy" to "zfs destroy -n"
### Apparently it started to face the same issues as my previous attempts.
### Not sure if I've missed something but at this point I did not want to continue to play with this script.
###
### The solution was to receive in a child of the encryptionroot(which I've created once again):

# zfs send --verbose --replicate -Lc bkp_prime/bkp/prime/lxc@bkp-nightly-2022-01-20-0015 \
| \
zfs receive -Fuv -x mountpoint -x canmount -x encryption -x keyformat -x keylocation -x overlay rpool/lxc/prime/tmp

# zfs rename rpool/lxc/prime rpool/lxc/prime-enc
# zfs change-key -o keylocation=file:///path/to/zfs-key -o keyformat=passphrase rpool/lxc/prime-enc/tmp
# zfs rename rpool/lxc/prime-enc/tmp rpool/lxc/prime
# zfs destroy rpool/lxc/prime rpool/lxc/prime-enc

References:

• https://zfsonlinux.topicbox.com/groups/zfs-discuss/Tc9acf1bc1513ea21/migration-from-unencrypted-to-encrypted-data-set