Bcachefs vs. Linus

https://www.phoronix.com/news/Linus-Torvalds-Bcachefs-Regrets

 

Használja vki? Mi a tapasztalat?

( persicsb | 2024. 08. 26., h – 03:59 )

Amúgy azt, ami a cikkben a fő probléma, hogy Linus azon panaszkodik, hogy a merge window alatt nagyméretű patcheket küldenek be a fejlesztők, már kitárgyaltuk itt: https://hup.hu/comment/2843074

Linus sem a Bcachefs miatt panaszkodik, hanem mert "lots of development during the release cycles rather than before it".

Továbbra is tartom a véleményemet, hogy nincs jól definiálva a merge window.

Sanda gyanúm, hogy a nagyméretű patchek mögött az áll, hogy a fejlesztők így próbálnak szar kódot áttolni. Abban reménykednek, hogyha elég nagy a merge nyomás akkor nem fogják  a szarukat annyira átnézni.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Nem ertetted meg. Nem a merge window-ban bejovo nagy patchekkel van a baj, hanem a stabilizacios idoszakban (rc1 - rc7) bejovo nagy patchekkel. Es azt tanacsolja neki Linus, hogyha 1000 sort akar rc-ben patchelni, akkor az mar uj development es nem regresszio javitasa, ugyhogy varja meg a kovetkezo merge-windowt vele.

A commiter le is írja, hogy ennek egy részét a 6.12-be tervezték, de kiderült, hogy nem várhat:

Lots of little fixes and two big items, which were orgiinally slated for
the 6.12 merge window but turned out to be pretty important.
The big items are:
- rhashtable conversion for VFS inodes cache
  Thas was slated for the 6.12 merge window, but a deadlock was
  uncovered in __wait_for_freeing_inode(); bcachefs inverts the usual
  locking between the VFS inode cache and on disk (btree) locking, with
  some advantages and some extra trickyness. The result was that we were
  waiting (via __wait_for_freeing_inode()) on the evict -> clear_inode()
  path with btree locks held, which was a rare deadlock but undoubtedly
  also one of the sources of the SRCU warnings.

- new data structure for managing freelists in btree key cache
  This eliminates the btree key cache lock, and associated lock
  contention. User feedback is that this resolves the main source of the
  SRCU warnings we've been seeing - which means that on some of the big
  multithreaded workloads people are running the lock contention was
  really bad (threads piling up and causing O(n^2) wait times), if it
  was able to trigger a 10 second delay warning.

 

Szóval mindkettő a tesztelés alatt derült ki, és muszáj megcsinálni. Pont erre való a rc időszak, ekkor derülnek ki szélesebb körben is hibák a kiadott release candidate kernelekből. Ha egy rc kernelben lévő hibát nem lehet kis javítással megoldani, akkor csak nagy javítással lehet, az élet ilyen. Ezek nem új feature-ök, nem azért kerül be, mert a merge window után készült el, hanem mert tesztelés kimutatta, hogy nem várhat a javítás a 6.12-re.