// SPDX-License-Identifier: GPL-2.0-or-later
/*
drbd_bitmap.c
This file is part of DRBD by Philipp Reisner and Lars Ellenberg.
Copyright (C) 2004-2008, LINBIT Information Technologies GmbH.
Copyright (C) 2004-2008, Philipp Reisner <philipp.reisner@linbit.com>.
Copyright (C) 2004-2008, Lars Ellenberg <lars.ellenberg@linbit.com>.
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/bitmap.h>
#include <linux/vmalloc.h>
#include <linux/string.h>
#include <linux/drbd.h>
#include <linux/slab.h>
#include <linux/highmem.h>
#include "drbd_int.h"
/* OPAQUE outside this file!
* interface defined in drbd_int.h
* convention:
* function name drbd_bm_... => used elsewhere, "public".
* function name bm_... => internal to implementation, "private".
*/
/*
* LIMITATIONS:
* We want to support >= peta byte of backend storage, while for now still using
* a granularity of one bit per 4KiB of storage.
* 1 << 50 bytes backend storage (1 PiB)
* 1 << (50 - 12) bits needed
* 38 --> we need u64 to index and count bits
* 1 << (38 - 3) bitmap bytes needed
* 35 --> we still need u64 to index and count bytes
* (that's 32 GiB of bitmap for 1 PiB storage)
* 1 << (35 - 2) 32bit longs needed
* 33 --> we'd even need u64 to index and count 32bit long words.
* 1 << (35 - 3) 64bit longs needed
* 32 --> we could get away with a 32bit unsigned int to index and count
* 64bit long words, but I rather stay with unsigned long for now.
* We probably should neither count nor point to bytes or long words
* directly, but either by bitnumber, or by page index and offset.
* 1 << (35 - 12)
* 22 --> we need that much 4KiB pages of bitmap.
* 1 << (22 + 3) --> on a 64bit arch,
* we need 32 MiB to store the array of page pointers.
*
* Because I'm lazy, and because the resulting patch was too large, too ugly
* and still incomplete, on 32bit we still "only" support 16 TiB (minus some),
* (1 << 32) bits * 4k storage.
*
* bitmap storage and IO:
* Bitmap is stored little endian on disk, and is kept little endian in
* core memory. Currently we still hold the full bitmap in core as long
* as we are "attached" to a local disk, which at 32 GiB for 1PiB storage
* seems excessive.
*
* We plan to reduce the amount of in-core bitmap pages by paging them in
* and out against their on-disk location as necessary, but need to make
* sure we don't cause too much meta data IO, and must not deadlock in
* tight me
| 