Re: Out of space loop: skip_balance not working

[Qu Wenruo <wqu@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 2505 bytes --]



On 2023/6/17 13:11, Stefan N wrote:
> Hi Qu,
> 
> I believe I've got this environment ready, with the 6.2.0 kernel as
> before using the Ubuntu kernel, but can switch to vanilla if required.
> 
> I've not done anything kernel modifications for a solid decade, so
> would be keen for a bit of guidance.

Sure no problem.

Please fetch the kernel source tar ball (6.2.x) first, decompress, then 
apply the attached one-line patch by:

$ tar czf linux*.tar.xz
$ cd linux*
$ patch -np1 -i <the patch file>

Then use your running system kernel config if possible:

$ cp /proc/config.gz .
$ gunzip config.gz
$ mv config .config
$ make olddefconfig

Then you can start your kernel compiling, and considering you're using 
your distro's default, it would include tons of drivers, thus would be 
very slow. (Replace the number to something more suitable to your 
system, using all CPU cores can be very hot)

$ make -j12

Finally you need to install the modules/kernel.

Unfortunately this is distro specific, but if you're using Ubuntu, it 
may be much easier:

$ make bindeb-pkg

Then install the generated dpkg I guess? I have never tried kernel 
building using deb/rpm, but only manual installation, which is also 
distro dependent in the initramfs generation part.

# cp arch/x86/boot/bzImage /boot/vmlinuz-custom
# make modules_install
# mkinitcpio -k /boot/vmlinuz-custom -g /boot/initramfs-custom.img


The last step is to update your bootloader to add the new kernel, which 
is not only distro dependent but also bootloader dependent.

In my case, I go with systemd-boot with manually crafted entries.
But if you go Ubuntu I believe just installing the kernel dpkg would 
have everything handled?

Finally you can try reboot into the newer kernel, and try device add 
(need to add 4 disks), then sync and see if things work as expected.

Thanks,
Qu
> 
> I will recover a 1tb SSD and partition it into 4 in a USB enclosure,
> but failing this will use 4x loop devices.
> 
> On Tue, 13 Jun 2023 at 11:28, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>> In your particular case, since you're running RAID1C4 you need to add 4
>> devices in one transaction.
>>
>> I can easily craft a patch to avoid commit transaction, but still you'll
>> need to add at least 4 disks, and then sync to see if things would work.
>>
>> Furthermore this means you need a liveCD with full kernel compiling
>> environment.
>>
>> If you want to go this path, I can send you the patch when you've
>> prepared the needed environment.

[-- Attachment #2: 0001-btrfs-do-not-commit-transaction-when-adding-a-new-de.patch --]
[-- Type: text/x-patch, Size: 1044 bytes --]

From b55b383150a185d367dd3b7a820dbe1efc5cfc9d Mon Sep 17 00:00:00 2001
Message-ID: <b55b383150a185d367dd3b7a820dbe1efc5cfc9d.1686979163.git.wqu@suse.com>
From: Qu Wenruo <wqu@suse.com>
Date: Sat, 17 Jun 2023 13:15:30 +0800
Subject: [PATCH] btrfs: do not commit transaction when adding a new device

This is to address a ENOSPC situation where one has to add more than one
disks before having enough space to commit the current transaction.
(Including the one to add a new device).

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 fs/btrfs/volumes.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index df43093b7a46..b8f68d58f498 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -2773,7 +2773,7 @@ int btrfs_init_new_device(struct btrfs_fs_info *fs_info, const char *device_path
 		btrfs_sysfs_update_sprout_fsid(fs_devices);
 	}
 
-	ret = btrfs_commit_transaction(trans);
+	ret = btrfs_end_transaction(trans);
 
 	if (seeding_dev) {
 		mutex_unlock(&uuid_mutex);
-- 
2.41.0