From f04275d242fd07270e4e6533d992b884accee235 Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Tue, 9 Sep 2025 17:24:36 +0300 Subject: [PATCH] =?utf8?q?=D0=9D=D0=B5=D1=85=D0=B2=D0=B0=D1=82=D0=BA=D0=B0?= =?utf8?q?=20=D1=81=D0=B2=D0=BE=D0=B1=D0=BE=D0=B4=D0=BD=D0=BE=D0=B3=D0=BE?= =?utf8?q?=20=D0=BC=D0=B5=D1=81=D1=82=D0=B0=20=D0=BD=D0=B0=20btrfs?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit https://changelog.complete.org/archives/10852-btrfs-on-a-raspberry-pi https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSGangBlocks Я btrfs считал и не перестаю считать, читая множество статей кто с ней возился, недостойной фигнёй (как и почти всё что делают в Linux экосистеме). Она просто несерьёзна по сравнению с ZFS. Я понимаю что все эти CoW системы сложно устроены, что есть масса особенностей и нюансов, возможно довольно дорогих с точки зрения ресурсов. Но тут автор пишет о том, что при попытке распаковать 6.2GB на 128GB флешку, через 100MB он получает ошибку об отсутствии свободного места. Я (вроде) понимаю про greedy block allocation и как такое, судя по описанию, могло бы произойти, но... всему же есть разумный предел. Всё же невозможность распаковать данные обычной корневой файловой системы на 128GB флешку -- это уже даже нелогично. В ZFS, кстати, тоже советуют стараться оставлять 10%+ места свободного, чтобы не усугублять фрагментацию. Но я не раз доводил некоторые свои накопители до заполненности такой, что он активно принимался создавать gang blocks (худшее что может быть). Но всё вполне себе работало. -- 2.52.0