vault backup: 2025-01-19 21:14:51

15 files changed, 110 insertions, 0 deletions

diff --git a/0 Inbox/.gitkeep b/0 Inbox/.gitkeep
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/0 Inbox/.gitkeep
diff --git a/0 Inbox/Image updater issue.md b/0 Inbox/Image updater issue.md
new file mode 100644
index 0000000..85af9ad
--- /dev/null
+++ b/0 Inbox/Image updater issue.md
@@ -0,0 +1,10 @@
+---
+tags:
+  - reflectie
+  - openstack
+  - code-review
+---
+There was an issue with the image updater, setting the tags on creating the image - rather than after waiting until it's completed.
+I didn't realise this would be an issue while reviewing the changes of Mohammed.
+
+Hoe kan ik mezelf trainen in het beter worden om zulke issues meteen te zien als ik er zelf niet mee bezig ben?
\ No newline at end of file
diff --git a/0 Inbox/Make filesystems.md b/0 Inbox/Make filesystems.md
new file mode 100644
index 0000000..ffdffc0
--- /dev/null
+++ b/0 Inbox/Make filesystems.md
@@ -0,0 +1,8 @@
+---
+tags:
+  - linux
+  - "#filesystem"
+---
+mkfs.fat
+mkfs.ext4
+..etc 
\ No newline at end of file
diff --git a/0 Inbox/Reminders.md b/0 Inbox/Reminders.md
new file mode 100644
index 0000000..d64141f
--- /dev/null
+++ b/0 Inbox/Reminders.md
@@ -0,0 +1,8 @@
+Puffen om en om
+Nu 2 tablet
+Morgen elke dag 1
+
+15 feb 11u zaterdag <- maria jurk inkorten
+
+Manchetknopen
+3 voor de bruiloft AVBA bezoeken pak op maat maken -> ff bellen afspraak, dinsdag of vrijdag -> vrijdagochtend voorkeur 
\ No newline at end of file
diff --git a/0 Inbox/Snapshot restore procedure.md b/0 Inbox/Snapshot restore procedure.md
new file mode 100644
index 0000000..6a63949
--- /dev/null
+++ b/0 Inbox/Snapshot restore procedure.md
@@ -0,0 +1,17 @@
+---
+tags:
+  - goba
+  - snapshot
+---
+stop server if active
+
+clone snapshot -> out comes a filesystem -> `{fs-name}-clone`
+- `sudo zfs clone <snapshot> <fs-name(-clone)>`
+promote said filesystem
+- `sudo zfs promote <fs-name(-clone)>`
+rename original fs
+- `sudo zfs rename <fs-name> <fs-name-datetime>`
+rename cloned snapshot to original fs
+- `sudo zfs rename <fs-name(-clone)> <fs-name>`
+
+start server if it was active
diff --git a/0 Inbox/System feedback.md b/0 Inbox/System feedback.md
new file mode 100644
index 0000000..92958db
--- /dev/null
+++ b/0 Inbox/System feedback.md
@@ -0,0 +1,3 @@
+I read an article somewhere about control plane feedback: any action we take should give (direct) feedback.
+
+This idea can be extended to a control panel implementation, e.g an openstack control panel. Where any action you do provides you with instant feedback. Think of creating a server; but it fails somewhere down the line due to an IP being allocated already. We want to know that so we can try again with another IP.
\ No newline at end of file
diff --git a/0 Inbox/Taskflow.md b/0 Inbox/Taskflow.md
new file mode 100644
index 0000000..07e7c22
--- /dev/null
+++ b/0 Inbox/Taskflow.md
@@ -0,0 +1,5 @@
+storage layer        \
+notifications           < - > task i/o
+persistence layer /
+
+Recommended way to provide flow inputs: store parameter.
\ No newline at end of file
diff --git a/0 Inbox/Thursday,  16 Jan 2025.md b/0 Inbox/Thursday,  16 Jan 2025.md
new file mode 100644
index 0000000..ce2c65a
--- /dev/null
+++ b/0 Inbox/Thursday,  16 Jan 2025.md
@@ -0,0 +1,14 @@
+---
+tags:
+  - daily
+  - "#unfinished-tasks"
+---
+# Tasks
+- [ ] Organize previous daily note
+- [ ] Configure VPN's with NetworkManager rather than systemd
+- [ ] Maria TAF overlijdensverzekering uitzoeken
+
+# Work
+- [x] Try to get a POC of taskflow resumption working
+- [ ] Implement it on the testpod
+- [x] Check snapshots production
\ No newline at end of file
diff --git a/0 Inbox/Virtual block device per QEMU.md b/0 Inbox/Virtual block device per QEMU.md
new file mode 100644
index 0000000..6e612d6
--- /dev/null
+++ b/0 Inbox/Virtual block device per QEMU.md
@@ -0,0 +1,8 @@
+---
+tags:
+  - linux
+  - filesystem
+references:
+  - https://wiki.qemu.org/Documentation/9p_root_fs
+---
+**Transparency and Shared File Access**: The classical way to deploy a virtualized OS (a.k.a. "guest") on a physical machine (a.k.a. "host") is to create a virtual block device (i.e. one huge file on host's filesystem) and leave it to the guest OS to format and maintain a filesystem ontop of that virtualized block device. As that filesystem would be managed by the guest OS, shared file access by host and guest simultaniously is usually cumbersome and problematic, if not even dangerous. A 9p passthrough-filesystem instead allows convenient file access by both host and guest simultaniously as the filesystem is just a regular subdirectory somewhere inside host's own filesystem.
\ No newline at end of file
diff --git a/0 Inbox/Write from a new-guy perspective.md b/0 Inbox/Write from a new-guy perspective.md
new file mode 100644
index 0000000..13c046b
--- /dev/null
+++ b/0 Inbox/Write from a new-guy perspective.md
@@ -0,0 +1,6 @@
+---
+tags:
+  - note-taking
+  - 2nd-brain
+---
+When documenting or noting something - I think it's always a good idea to take a new-guy perspective to it. Which means to really try and dissect and understand exactly what's being written.
\ No newline at end of file
diff --git a/0 Inbox/Writeback cache.md b/0 Inbox/Writeback cache.md
new file mode 100644
index 0000000..83495c4
--- /dev/null
+++ b/0 Inbox/Writeback cache.md
@@ -0,0 +1,28 @@
+---
+tags:
+  - linux
+  - qemu
+  - filesystem
+references:
+  - https://avidandrew.com/understanding-disk-cache-writeback-ext4.html
+  - https://docs.kernel.org/admin-guide/sysctl/vm.html#dirty-expire-centisecs
+---
+normal: write() -> cache (multiple layers) -> disk
+
+# Physical server write cache
+![[physical_write_cache.png]] 
+
+Page cache -> RAM
+
+Journal -> ensures data is fully written before the transaction is considered complete.
+`commit` mount option -> flushes cache to disk every x seconds (configurable)
+`barrier` mount option -> enables the ordering of groups of writes, controller ensures writes before barrier are written before writes after barrier.
+
+`commit` + dirty_expire_centisecs [2] ~ automatic persisting of data.
+
+If we call `sync`, `fsync` or `fdatasync` ourselves our data is forced on-disk right away by the kernel, no need to wait for commit + dirty_expirty_centisecs.
+
+# VM Write cache
+ Guest has its own page cache
+ ![[vm_write_cache.png]]
+ 
\ No newline at end of file
diff --git a/0 Inbox/gitlab workflows.md b/0 Inbox/gitlab workflows.md
new file mode 100644
index 0000000..e309f6e
--- /dev/null
+++ b/0 Inbox/gitlab workflows.md
@@ -0,0 +1,2 @@
+GitHub’s merge queue and GitLab’s merge train workflows
+https://techdoc.one.com/guides/gitlab/marge-bot/
\ No newline at end of file
diff --git a/0 Inbox/physical_write_cache.png b/0 Inbox/physical_write_cache.png
new file mode 100644
index 0000000..819c834
--- /dev/null
+++ b/0 Inbox/physical_write_cache.png
diff --git a/0 Inbox/ssh.md b/0 Inbox/ssh.md
new file mode 100644
index 0000000..25258cc
--- /dev/null
+++ b/0 Inbox/ssh.md
@@ -0,0 +1 @@
+automatisch throttle bij hoge throttling <- tcp doet dat ook
\ No newline at end of file
diff --git a/0 Inbox/vm_write_cache.png b/0 Inbox/vm_write_cache.png
new file mode 100644
index 0000000..1c63843
--- /dev/null
+++ b/0 Inbox/vm_write_cache.png