Hello,
Sorry I really thought I could accomplish this with BPF, but ref tracking is
just too complicated to work properly with BPF. I forward ported my ref
verification patch to the latest kernel, you can find it in the btrfs-readdir
branch of my btrfs-next tree here
git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git
Just check that out, git checkout btrfs-readdir, build with
CONFIG_BTRFS_FS_REF_VERIFY=y, and then mount the problematic fs with –o
ref_verify and then grab the full output when it blows up and we should be able
to work out what is happening from there. Thanks,
Josef
On 8/29/17, 11:41 PM, "Marc MERLIN" <m...@merlins.org> wrote:
On Tue, Aug 29, 2017 at 06:22:38PM +0000, Josef Bacik wrote:
> How much metadata do you have on this fs? I was going to hold everything in
> bpf hash trees, but I’m worried we’ll hit collisions and then the tracing
> will be useless. If it’s too big I’ll have to dump everything to userspace
> and let python take care of keeping everything in memory, so if you have a
> lot of metadata hopefully you have lots of memory too ;). Thanks,
gargamel:~# btrfs fi df /mnt/btrfs_pool1
Data, single: total=10.60TiB, used=10.54TiB
System, DUP: total=32.00MiB, used=1.19MiB
Metadata, DUP: total=58.00GiB, used=12.69GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page:
https://urldefense.proofpoint.com/v2/url?u=http-3A__marc.merlins.org_&d=DwIDaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=sDzg6MvHymKOUgI8SFIm4Q&m=q-HXS1ddbqcYmJLp6pXcQoJL7qBXplbRAFRQ4eGSQYw&s=yyIlFUXCBjQ2xLoWBYzasW3BtBiLrITfkKLWvnhqgOs&e=
| PGP 1024R/763BE901
