Am Donnerstag, 23. Juni 2011 schrieb Josef Bacik: > On Thu, Jun 23, 2011 at 07:37:12PM +0200, Martin Steigerwald wrote: > > Hi! > > > > Short summary: I suspect that rsync´ing files to a newly created > > BTRFS partition with a subvolume *and* enabled space_cache triggers > > the error mentioned in the subject line of this mail. I reported > > this also as: > > > > Bug 38112 - btrfs: failed to load free space cache for block group > > on rsync´ing to space_cache BTRFS with subvolume > > > > https://bugzilla.kernel.org/show_bug.cgi?id=38112 > > > > I will add a reference to my post here to the bug report, so feel > > free to use whatever suits you best to follow up. > > > > > > This happened on a ThinkPad T520 with 3.0.0-rc3-amd64 Debian/GNU > > Linux kernel. The issue happened on a 2.5 inch external eSATA/USB > > harddisk which I changed to BTRFS. On the repoot after the rsync > > process was stalled the unrelated non space cache using root > > filesystem did not mount anymore with 3.0.0-rc3-amd64 and > > 2.6.39-2-amd64 kernel. But thankfully it did mount with a 2.6.38 > > grml 2011 amd64 kernel and now work again. > > > > > > Thus I did > > > > merkaba:~> mkfs.btrfs -L daten /dev/sdc2 > > > > WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL > > WARNING! - see http://btrfs.wiki.kernel.org before using > > > > fs created label daten on /dev/sdc2 > > > > nodesize 4096 leafsize 4096 sectorsize 4096 size 447.13GB > > > > Btrfs Btrfs v0.19 > > > > merkaba:~> mount -o space_cache,compress=lzo /dev/sdc2 > > /mnt/amazon-daten merkaba:~> dmesg | tail -3 > > [137440.930038] device label daten devid 1 transid 7 /dev/sdc2 > > [137440.930507] btrfs: enabling disk space caching > > [137440.930518] btrfs: use lzo compression > > > > > > Then I unmounted, added a fstab entry without space_cache option > > since I read that once BTRFS created a space_cache it would use it > > anyway it is mounted with clear_cache to clear the cache again. > > > > I created a sub volume for movies, cause I wanted to be able to not > > snapshot the movie files: > > > > merkaba:~> btrfs subvolume create /mnt/amazon-daten/Filme > > Create subvolume '/mnt/amazon-daten/Filme' > > > > I then did my rsync from the backup which BTW was a BTRFS with > > space_cache as well - created today: > > > > merkaba:~> rsync -a -H --acls --xattrs --sparse > > /mnt/steigerwald-daten/ /mnt/amazon-daten > > > A short while after starting the rsync I got: > I've just posted a patch for this, sorry about that I've fixed this > before but there has been recent work in this area to make it more > generic and we lost that particular fix. Thanks,
Is it: [PATCH] Btrfs: make sure to update total_bitmaps when freeing cache V2 ? Do you need testing? Is this scheduled for 3.0.0-rc5 or something like this? Then I could wait for the Debian kernel 3.0.0-rc5 to become available. I can do without space_cache for the time being. I am a bit reluctant with testing as even tough the problem happened on a different filesystem my root filesystem located on a different was not mountable with 2.6.39 and 3.0.0-rc3. Too bad I didn´t take a photo of the backtrace that dumped me to initramfs. I can try this again, hoping, that again 2.6.38 grml will mount this, but I am a bit wary with that. Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
