| 14 Mar 2026 |
 lassulus | I have a vague memory that it also happens on other FS | 19:48:25 |
 Mic92 | But not 100 percent sure. Would have to check the Kernel code | 19:49:02 |
| Mic92 | Also this should probably take into account how much memory we give to the vm | 19:49:58 |
| lassulus | probably, but we don't need any cache for paths we copy once from one fs to the other? | 19:50:21 |
| Mic92 | Well it might also hurt Io scheduling | 19:50:57 |
| Mic92 | If you flush more often | 19:51:09 |
| Mic92 | CP/rsync are probably doing direct I/o as well | 19:52:10 |
| Mic92 | This usually by passes page cache | 19:52:32 |
| lassulus | cp doesn't seem to do it, otherwise this would not happen? | 19:52:50 |
| lassulus | or it's a different issue | 19:53:08 |
| Mic92 | Has been to long since I did that. I with it did something like read into mmap? This would actually not be direct Io but don't remember the mmap flags it used | 19:54:21 |
| Mic92 | * Has been to long since I read that. I with it did something like read into mmap? This would actually not be direct Io but don't remember the mmap flags it used | 19:54:43 |
| Mic92 | * Has been to long since I read that. I think it did something like read into mmap? This would actually not be direct Io but don't remember the mmap flags it used | 19:55:19 |
| Mic92 | Some of them tell the Kernel to not bother with page cache | 19:56:06 |
 matthewcroughan | I think it is somehow dependent on the host | 20:04:40 |
| matthewcroughan | I have a reproducer now that only fails sometimes | 20:04:47 |
| matthewcroughan | Either that or it is dependent on some randomness | 20:05:42 |
| matthewcroughan | does xargs sort things on the way in? | 20:05:54 |
| lassulus | good question, maybe not | 20:06:20 |
| matthewcroughan | even if it was that, and you sorted it, that only means for the same closure you would get the same bug, rather than it failing randomly | 20:06:45 |
| matthewcroughan | but the root cause would still be there | 20:06:51 |
| lassulus | maybe we just create like 8x1gb files and copy that into the new image? for a reproducer | 20:07:02 |
| Mic92 | In reply to @lassulus:lassul.us
good question, maybe not Should be stable because closure info stays the same | 20:19:38 |
| Mic92 | The parallel flag might introduce some non-determinism | 20:20:07 |
| matthewcroughan | lassulus: if you want a minimal reproducer for ZFS | 20:29:49 |
| matthewcroughan | no PR needed | 20:29:57 |
| matthewcroughan | diff --git a/tests/make-disk-image.nix b/tests/make-disk-image.nix
index eb81f15..2308836 100644
--- a/tests/make-disk-image.nix
+++ b/tests/make-disk-image.nix
@@ -5,10 +5,11 @@
(pkgs.nixos [
../module.nix
- ../example/simple-efi.nix
+ ../example/zfs.nix
(
{ config, ... }:
{
+ networking.hostId = "8425e349";
documentation.enable = false;
system.stateVersion = config.system.nixos.release;
disko.memSize = 2048;
| 20:30:00 |
| matthewcroughan | This will cause a kernel panic | 20:30:10 |
| matthewcroughan | nixos-disko-images> + zfs create -up zroot/encrypted -o encryption=aes-256-gcm -o keyformat=passphrase -o keylocation=file:///tmp/secret.key -o mountpoint=none
nixos-disko-images> cannot create 'zroot/encrypted': Failed to open key material file: No such file or directory
Maybe that's the reason though?
| 20:30:40 |
| matthewcroughan | Yeah okay, maybe that's all it is.. | 20:31:56 |
