On Thu, Aug 31, 2017 at 05:48:23PM +0000, Josef Bacik wrote:
> We are using 4.11 in production at fb with backports from recent (a month
> ago?) stuff. I’m relatively certain nothing bad will happen, and this branch
> has the most recent fsync() corruption fix (which exists in your kernel so
> it’s not new). That said if you are uncomfortable I can rebase this patch
> onto whatever base you want and push out a branch, it’s your choice. Keep in
> mind this is going to hold a lot of shit in memory, so I hope you have
> enough, and I’d definitely remove the sleep’s from your script, there’s no
> telling if this is a race condition or not and the overhead of the ref-verify
> stuff may cause it to be less likely to happen. Thanks,
Thanks for the warning. I have 32GB of RAM in the server, and I probably use
8. Most of the rest is so that I can do btrfs check --repair without the
machine dying :-/
I am concerned that I have a lot more metadata than I have memory:
gargamel:~# btrfs fi df /mnt/btrfs_pool1
Data, single: total=10.66TiB, used=10.60TiB
System, DUP: total=32.00MiB, used=1.20MiB
Metadata, DUP: total=58.00GiB, used=12.76GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
gargamel:~# btrfs fi df /mnt/btrfs_pool2
Data, single: total=5.07TiB, used=4.78TiB
System, DUP: total=8.00MiB, used=640.00KiB
Metadata, DUP: total=70.50GiB, used=66.58GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
That's 13GB + 67GB.
Is it going to fall over if I only have 32GB of RAM?
If I stop mounting /mnt/btrfs_pool2 for a while, will 32GB of RAM
cover the 13GB of metadata from /mnt/btrfs_pool1 ?
Thanks,
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: http://marc.merlins.org/
--
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
