On Wed, 20 Apr 2011 00:55:31 +0300 Sergei Trofimovich <slyich@xxxxxxxxx> wrote: > > Thanks a lot for testing, though. > > > > I guess something messed up your btrfs metadata, cause when btrfs_unlink() wanted to remove A, > > it found that A was just missing... Yeah. Now I think I completely figured out what's going on: My mixed partition was correct except it did'n have MIXED bit in superblock (I mistakenly used LZO bit for that in btrfs-progs, as I took some old patch from maillist). Thus I had D+M marked (aka mixed) block groups, but from superblock's features there was no way to figure out there is yet such groups. That's why your second patch (looking correct) didn't help me. I've fallen to mixed == 0 case. > I think interesting the parts are (they were found by Arne before): > [ 0.040000] new update_space_info: > [ 0.040000] space_info has 0 free, is not full > [ 0.040000] space_info total=0, used=0, pinned=0, reserved=0, may_use=0, readonly=0 > [ 0.040000] new update_space_info: > [ 0.040000] space_info has 0 free, is not full > [ 0.040000] space_info total=0, used=0, pinned=0, reserved=0, may_use=0, readonly=0 > [ 0.040000] new update_space_info: > [ 0.040000] space_info has 0 free, is not full > [ 0.040000] space_info total=0, used=0, pinned=0, reserved=0, may_use=0, readonly=0 Talking with Arne I was convinced my breakage is not worth fixing in kernel. After I've added MIXED bit to superblocks' features OOpses gone. So, once again, please disregard my OOpses. -- Sergei
Attachment:
signature.asc
Description: PGP signature
