Re: btrfs: failed to load free space cache for block group on rsync´ing to space_cache BTRFS with subvolume

[Martin Steigerwald <Martin@lichtvoll.de>]

Am Donnerstag, 23. Juni 2011 schrieb Josef Bacik:
> On Thu, Jun 23, 2011 at 07:37:12PM +0200, Martin Steigerwald wrote:
> > Hi!
> >=20
> > Short summary: I suspect that rsync=B4ing 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:
> >=20
> > Bug 38112 -  btrfs: failed to load free space cache for block group
> > on rsync=B4ing to space_cache BTRFS with subvolume
> >=20
> > https://bugzilla.kernel.org/show_bug.cgi?id=3D38112
> >=20
> > 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.
> >=20
> >=20
> > 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.
> >=20
> >=20
> > Thus I did
> >=20
> > merkaba:~> mkfs.btrfs -L daten /dev/sdc2
> >=20
> > WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
> > WARNING! - see http://btrfs.wiki.kernel.org before using
> >=20
> > fs created label daten on /dev/sdc2
> >=20
> >         nodesize 4096 leafsize 4096 sectorsize 4096 size 447.13GB
> >=20
> > Btrfs Btrfs v0.19
> >=20
> > merkaba:~> mount -o space_cache,compress=3Dlzo /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
> >=20
> >=20
> > 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.
> >=20
> > I created a sub volume for movies, cause I wanted to be able to not
> > snapshot the movie files:
> >=20
> > merkaba:~> btrfs subvolume create /mnt/amazon-daten/Filme
> > Create subvolume '/mnt/amazon-daten/Filme'
> >=20
> > I then did my rsync from the backup which BTW was a BTRFS with
> > space_cache as well - created today:
> >=20
> > merkaba:~> rsync -a -H --acls --xattrs --sparse
> > /mnt/steigerwald-daten/ /mnt/amazon-daten
>=20
> > 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=20
this? Then I could wait for the Debian kernel 3.0.0-rc5 to become=20
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=20
different filesystem my root filesystem located on a different was not=20
mountable with 2.6.39 and 3.0.0-rc3. Too bad I didn=B4t take a photo of=
 the=20
backtrace that dumped me to initramfs. I can try this again, hoping, th=
at=20
again 2.6.38 grml will mount this, but I am a bit wary with that.

Thanks,
--=20
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html