0 Members and 1 Guest are viewing this topic.
Du weisst aber schon, dass der Hauptentwickler von Btrfs schon beim Mörder in Lohn und Brot stand?
Redhat beauftragte im Q2/2010 Edward Shishkin, einen der ursprünglichen Reiser4 Entwickler, mit einem Codereview. Shishkins Schluss war, dass das Design fehlerhaft ist, da dem ursprünglichen Algorithmus in Kernpunkten nicht gefolgt wird. Die Designfehler führen dazu, dass in speziellen Fällen der Plattenplatz ausgehen kann, obwohl genügend Platz vorhanden ist.[16][17][18]Eine stabile btrfs-Version (mit dem endgültigen Datenformat - Version 1.0) war ursprünglich für 2008 zur Veröffentlichung vorgesehen, wurde jedoch bisher (Mai 2011) noch nicht veröffentlicht. Nichtsdestoweniger ist die Unterstützung bereits in die Hauptversion des Linux-Kernels aufgenommen (seit Version 2.6.29-rc1). Bei einigen Linux-Distributionen steht das Dateisystem bereits offiziell bei der Installation zur Auswahl.
Hi Jeff,The day after the openSUSE conference, Jos showed me his laptop and aproblem with it under the most recent Tumbleweed kernel (and olderkernels as well.)He is copying a very large (3Gb) file to his btrfs partition from a USBexternal drive (running ext3) such that if it succeeds, the partitionwill almost be full (only a few Mb left). This should be fine, but italmost kills the system, slowing responsiveness down to nothing beingpossible to do at all on the box until the copy completes 15+ minuteslater. It is possible to eventually interrupt the copy, and when thathappens, the system returns back to life.Copying the other way (from the btrfs partition to the USB disk), worksabsolutly fine, so it doesn't seem like the system is hurting frommemory pressure on anything else.Is this a currently-known issue on btrfs when the filesystem is almostout of space and it just takes forever to find empty blocks in which toput things, or is it something that we should log in a bugzilla entryand try to get resolved?thanks,greg k-h