Next update

[janos666]

I see you usually update these drivers roughly once a year. Could you please include Btrfs "extent tree v2" support in this year's update? It presumably increases the mount time significantly. I love how my box boots directly from Btrfs after injecting your driver into the motherboard's UEFI firmware but boot time is ridiculously slow this way (I guess the CPU is operating at it's lowest possible frequency during that time and these drivers might not be optimized for speed either). The kernel mounts the HDD-based RAID filesystem without a few seconds with or without that new Btrfs feature but the motherboard firmware takes a few minutes in comparison. So, a theoretical ~50x speedup in firmware-mount time would be very very perceivable (could reduce minutes to seconds).

https://www.reddit.com/r/btrfs/comments/xgqct8/btrfsprogs_separate_block_group_tree_from_extent/

[pbatard]

I see you usually update these drivers roughly once a year.

I'm afraid that this is not really the case.

There's no schedule or plan when it comes EfiFs updates and I only do update the drivers when the circumstances are favourable and when I happen to have enough free time in front of me.

So let me start by dashing your hopes of seeing an update to EfiFs anytime soon, on account that the current gnu-efi, which EfiFs relies when it comes to its development, has been left in a broken state by Red Hat, openSUSE & co (See https://sourceforge.net/p/gnu-efi/bugs/38/ as well as https://sourceforge.net/p/gnu-efi/bugs/37/), who completely disregarded the fact that the project is a multi-OS, multi-toolchain project rather than something Linux-centric that they could shoehorn into their specific needs, and also appear to consider, since they are continuing to disregard a major regression, that investing resources to fix stuff that they happened to break is beneath them...

All in all, this makes me exceedingly reluctant to continue work on any project that relies on gnu-efi, such as EfiFs, because it leaves me with two choices that I am equally uncomfortable with:

1. Either drop gnu-efi from the project altogether, which will make development extremely painful, as integrating EDK2 compilation into Visual Studio is a major pain in the ass and, even if it was easy, it will always result in compilation and testing times that are a lot longer than the gnu-efi based ones.
2. Either stick with an old version of gnu-efi, which leaves me with no path for updates/upgrades on that front, and is already actually an issue as I had gnu-efi patches lined up for RISC-V compilation.

Thus, whereas I would like to be able to say that I'm planning to update EfiFs to help with your issue sometime soon, the reality is that the current gnu-efi situation pretty much made me lose the drive that invited me to push forward with this project. As such, you shouldn't expect updates to EfiFs anytime soon...

[janos666]

Thank you for the information (and your past work on this regardless).

[pbatard]

By the way, since it appears you are also under the impression that I get to decide the features that get added to the file system code, and can therefore pick things at at will, please be aware that this is very far from the truth.

For a file system feature to be proposed by EfiFs, it must first be added to the GRUB project, since I do not perform any development when it comes to the file systems at all (that would be way too much work!), but am merely reusing the existing GRUB code, and I am not seeing anything related to Btrfs "extent tree v2" support in there.

So, if you do want that feature in EfiFs, you're going to first have to wait until someone thinks that this is a feature that GRUB needs, and is willing to implement it there or you will have to propose a patch to GRUB yourself because that is the only way you will see a specific file system functionality appear in EfiFs.

As a result, I will close this issue.