This is an awesome talk for nerding out on ZFS interna. ?
https://www.youtube.com/watch?v=qkA5HhfzsvM
This is an awesome talk for nerding out on ZFS interna. ?
If you were to design a threading library today how would it look like? David Beazley manages to demonstrate a lot of edge cases in tiny examples … while live-coding! ?
A remarkably sober analysis of what problem systemd solves for Linux … at a BSD conference of all places. ?
When I started playing with LXD I just accepted the default storage configuration which creates an image file and uses that to initialize a ZFS pool. Since I’m using ZFS as my main file system this seemed silly as LXD can use an existing dataset as a source for a storage pool. So I wanted to migrate my existing containers to the new storage pool.
Although others seemed to to have the same problem there was no ready answer. Digging through the documentation I finally found out that the lxc move command had a -s option … I had an idea. ? Here’s what I came up with …
First we create the dataset on the existing ZFS pool and add it to LXC.
sudo zfs create -o mountpoint=none mypool/lxd lxc storage create pool2 zfs source=mypool/lxd
lxc storage list should show something like this now:
+-------+-------------+--------+--------------------+---------+ | NAME | DESCRIPTION | DRIVER | SOURCE | USED BY | +-------+-------------+--------+--------------------+---------+ | pool1 | | zfs | /path/to/pool1.img | 2 | +-------+-------------+--------+--------------------+---------+ | pool2 | | zfs | mypool/lxd | 0 | +-------+-------------+--------+--------------------+---------+
pool1 is the old pool backed by the image file and is used by some containers at the moment as can be seen in the “Used By” column. pool2 is added by not used by any contaiers yet.
We now try to move our containers to pool2.
# move container to pool2 lxc move some_container some_container-moved -s=pool2 # rename container back for sanity ;) lxc move some_container-moved some_container
We can check with lxc storage list whether we succeeded.
+-------+-------------+--------+--------------------+---------+ | NAME | DESCRIPTION | DRIVER | SOURCE | USED BY | +-------+-------------+--------+--------------------+---------+ | pool1 | | zfs | /path/to/pool1.img | 1 | +-------+-------------+--------+--------------------+---------+ | pool2 | | zfs | mypool/lxd | 1 | +-------+-------------+--------+--------------------+---------+
Indeed pool2 is beeing used now. ? Just to be sure we check that zfs list -r mypool/lxd also reflects this.
NAME USED AVAIL REFER MOUNTPOINT mypool/lxd/containers 1,08G 92,9G 24K none mypool/lxd/containers/some_container 1,08G 92,9G 704M /var/snap/lxd/common/lxd/storage-pools/pool2/containers/some_container mypool/lxd/custom 24K 92,9G 24K none mypool/lxd/deleted 24K 92,9G 24K none mypool/lxd/images 24K 92,9G 24K none mypool/lxd/snapshots 24K 92,9G 24K none
Awesome!
⚠ Note that this only moves the container, but not the LXC image it was cloned off of.
We can repeat this until all containers we care about are moved over to pool2.
To prevent new containers to use pool1 we have to edit the default profile.
# change devices.root.pool to pool2 lxc profile edit default
Finally …. when we’re happy with the migration and we’ve verified that everything works as expected we can now remove pool1.
lxc storage rm pool1
This made my day.
Things that happen in Silicon Valley and also the Soviet Union:
– waiting years to receive a car you ordered, to find that it's of poor workmanship and quality
– promises of colonizing the solar system while you toil in drudgery day in, day out
— anton (𝔴𝔞𝔯𝔱𝔦𝔪𝔢) (@atroyn) July 5, 2018
IEEE supports the use of unfettered strong encryption to protect confidentiality and integrity of data and communications. We oppose efforts by governments to restrict the use of strong encryption and/or to mandate exceptional access mechanisms such as “backdoors” or “key escrow schemes” in order to facilitate government access to encrypted data. Governments have legitimate law enforcement and national security interests. IEEE believes that mandating the intentional creation of backdoors or escrow schemes – no matter how well intentioned – does not serve those interests well and will lead to the creation of vulnerabilities that would result in unforeseen effects as well as some predictable negative consequences.
— IEEE Position Statement
Thomas Dullien of Google’s Project Zero on why security suffers because it’s actually cheaper to build more complex things (i.e. ship some piece of hardware with a general purpose processor and define features in software instead of using a purpose-built chip).
An interesting talk about Lego CAD with some glimpses into “after market” Lego. 😀
Dan Luu has a nice collection of interesting Hacker News posts.