On Mon, Oct 29, 2012 at 8:20 PM, Liu Bo [off-list ref] wrote:

On 10/30/2012 04:06 AM, Mitch Harder wrote:

quoted

On Sat, Oct 27, 2012 at 5:28 AM, Liu Bo [off-list ref] wrote:

quoted

This comes from one of btrfs's project ideas,
As we defragment files, we break any sharing from other snapshots.
The balancing code will preserve the sharing, and defrag needs to grow this
as well.

Now we're able to fill the blank with this patch, in which we make full use of
backref walking stuff.

Here is the basic idea,
o  set the writeback ranges started by defragment with flag EXTENT_DEFRAG
o  at endio, after we finish updating fs tree, we use backref walking to find
   all parents of the ranges and re-link them with the new COWed file layout by
   adding corresponding backrefs.

Originally patch by Li Zefan [off-list ref]
Signed-off-by: Liu Bo <redacted>
---
v3->v4:
      - fix duplicated refs bugs detected by mounting with autodefrag, thanks
        for the bug report from Mitch and Chris.

I'm picking up many WARN_ON messages while testing this patch.

I'm testing a snapshot script that uses kernel git sources along with
some git manipulations.

The kernel is a 3.6.4 kernel merged with the latest for-linus branch.

I mounted with -o compress-force=lzo,autodefrag.

I also have the second patch in this set (Btrfs: make snapshot-aware
defrag as a mount option).  However, I did not mount with
'snap_aware_defrag'.

I did not find any corrupted data, and the partition passes a btrfsck
without error after these warnings were observed.

Hi Mitch,

Well, good report, but I don't think it has anything to do with this patch(since you
didn't mount with 'snap_aware_defrag' :)

I've re-run my my testing script with a combination of no compression
and lzo compression, combined with no further options, only -o
autodefrag, and -o autodefrag,snap_aware_defrag.

I only get the WARN_ONs when I run with autodefrag only (no snap_aware_defrag).

My logs are clean when I avoid all defrag options, or use both
autodefrag and snap_aware_defrag.

After going through the below messages, the bug comes from the space side where we
must have mis-used our reservation somehow.

So can you show me your script so that I can give it a shot to reproduce locally?