Bei dpkg ist ja bekannt, dass es sehr viele fsync()-Aufrufe macht. Scheint (schien?) also so zu sein, dass btrfs bei vielen fsync() aufrufen etwa sins stocken gerät. Fairerweise muss man aber auch erwähnen, dass in sehr vielen Programmen das fsync() völlig falsch oder unnütz eingesetzt wird. Linus Torvalds hat sich darüber auh schonmal irgendwo drüber ausgelassen...
Der bug ist 1,5 Jahre alt, sicher dass das keine alte Klamotte ist?
Also das dpkg problem ist definitv noch vorhanden da. Auch auf ubuntu precise alpha mit kernel 3.2.5. Das habe ich da es stabiler ist als die final von 11.10 auf verschiedenen Rechnern im einsatz. Bei einigen habe ich btrfs root getestet. Start dauert gefühlt doppelt so lang. Update von 20 Packages (ohne download) ext4 unter einer minute btrfs etwa 20 minuten
Die Hauptursache des Problems ist aber apt und seine unzähligen fsync()-Aufrufe. Bevor debian aber das apt dahingehend anpasst, forken sie eher btrfs und bauen einen Workaround ein
Bei dpkg ist ja bekannt, dass es sehr viele fsync()-Aufrufe macht. Scheint (schien?) also so zu sein, dass btrfs bei vielen fsync() aufrufen etwa sins stocken gerät. Fairerweise muss man aber auch erwähnen, dass in sehr vielen Programmen das fsync() völlig falsch oder unnütz eingesetzt wird. Linus Torvalds hat sich darüber auh schonmal irgendwo drüber ausgelassen...
Der bug ist 1,5 Jahre alt, sicher dass das keine alte Klamotte ist?
Also das dpkg problem ist definitv noch vorhanden da. Auch auf ubuntu precise alpha mit kernel 3.2.5.
Das habe ich da es stabiler ist als die final von 11.10 auf verschiedenen Rechnern im einsatz.
Bei einigen habe ich btrfs root getestet.
Start dauert gefühlt doppelt so lang.
Update von 20 Packages (ohne download)
ext4 unter einer minute
btrfs etwa 20 minuten
Die Hauptursache des Problems ist aber apt und seine unzähligen fsync()-Aufrufe. Bevor debian aber das apt dahingehend anpasst, forken sie eher btrfs und bauen einen Workaround ein