From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: linux-btrfs@vger.kernel.org, dsterba@suse.cz, jbacik@fb.com
Subject: [RFC PATCH v2.1 00/16] Introduce low memory usage btrfsck mode
Date: Tue, 17 May 2016 17:38:34 +0800 [thread overview]
Message-ID: <1463477930-3925-1-git-send-email-quwenruo@cn.fujitsu.com> (raw)
The branch can be fetched from my github:
https://github.com/adam900710/btrfs-progs.git low_mem_fsck_v2.1
======
RFC v2.1 patchset is a readability enhancement update.
======
Original btrfsck checks extent tree in a very efficient method, by
recording every checked extent in extent record tree to ensure every
extent will be iterated for at most 2 times.
However extent records are all stored in heap memory, and consider how
large a btrfs file system can be, it can easily eat up all memory and
cause OOM for TB-sized metadata.
Instead of such heap memory usage, we introduce low memory usage fsck
mode.
In this mode, we will use btrfs_search_slot() only and avoid any heap
memory allocation.
The work flow is:
1) Iterate extent tree
And check whether the referencer of every backref exists.
2) Iterate other trees
And check whether the backref of every tree block/data exists in
extent tree.
So in theory, every extent is iterated twice.
But since we don't have extent record, but use btrfs_search_slot() every
time we check, it may cause extra IO.
I assume the extra IO is reasonable and would make btrfsck able to
handle super large fs.
TODO features:
1) Fs tree check code
Fs tree check also eats a lot of memory.
Fixing extent tree check is not a final solution, fs check also needs
such rework, or we can still eat up a lot of memory
2) Repair
Repair should be the same as old btrfsck, but still need to determine
the repair principle.
Current repair sometimes uses backref to repair data extent,
sometimes uses data extent to fix backref.
We need a consistent principle, or we will screw things up.
3) Replace current fsck code
We assume the low memory mode has less lines of code, and may be
easier for review and expand.
If low memory mode is stable enough, we will consider to replace
current extent and chunk tree check codes to free a lot of lines.
Changelog:
v1.1:
Fix a typo which makes keyed data backref check always fail
v2:
Don't return minus value with error bits. (Suggested by Josef)
Follow kernel code styling. (Suggested by Josef)
Enhance check on data backref count. (Slow down check speed though)
v2.1:
Fix an error report which could access uninitialized keys
(Pointed out by David)
Improve readability by rename multiple btrfs_key to names which
represents its root or search destination.
Like in check_chunk_item(), rename keys to
"chunk_key","bg_key","devext_key" to avoid unintended
above overwrite/access to uninitialized key.
Slightly speedup block group used space accounting, by change its
search start to correct block group number.
checkpatch style fixes.
Lu Fengqi (16):
btrfs-progs: fsck: Introduce function to check tree block backref in
extent tree
btrfs-progs: fsck: Introduce function to check data backref in extent
tree
btrfs-progs: fsck: Introduce function to query tree block level
btrfs-progs: fsck: Introduce function to check referencer of a backref
btrfs-progs: fsck: Introduce function to check shared block ref
btrfs-progs: fsck: Introduce function to check referencer for data
backref
btrfs-progs: fsck: Introduce function to check shared data backref
btrfs-progs: fsck: Introduce function to check an extent
btrfs-progs: fsck: Introduce function to check dev extent item
btrfs-progs: fsck: Introduce function to check dev used space
btrfs-progs: fsck: Introduce function to check block group item
btrfs-progs: fsck: Introduce function to check chunk item
btrfs-progs: fsck: Introduce hub function for later fsck
btrfs-progs: fsck: Introduce function to speed up fs tree check
btrfs-progs: fsck: Introduce traversal function for fsck
btrfs-progs: fsck: Introduce low memory mode
Documentation/btrfs-check.asciidoc | 6 +
cmds-check.c | 1757 +++++++++++++++++++++++++++++++++---
ctree.h | 2 +
extent-tree.c | 2 +-
4 files changed, 1622 insertions(+), 145 deletions(-)
--
2.8.2
next reply other threads:[~2016-05-17 9:39 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-17 9:38 Qu Wenruo [this message]
2016-05-17 9:38 ` [RFC PATCH v2.1 01/16] btrfs-progs: fsck: Introduce function to check tree block backref in extent tree Qu Wenruo
2016-05-17 9:38 ` [RFC PATCH v2.1 02/16] btrfs-progs: fsck: Introduce function to check data " Qu Wenruo
2016-05-17 9:38 ` [RFC PATCH v2.1 03/16] btrfs-progs: fsck: Introduce function to query tree block level Qu Wenruo
2016-05-17 9:38 ` [RFC PATCH v2.1 04/16] btrfs-progs: fsck: Introduce function to check referencer of a backref Qu Wenruo
2016-05-17 9:38 ` [RFC PATCH v2.1 05/16] btrfs-progs: fsck: Introduce function to check shared block ref Qu Wenruo
2016-05-17 9:38 ` [RFC PATCH v2.1 06/16] btrfs-progs: fsck: Introduce function to check referencer for data backref Qu Wenruo
2016-05-17 9:38 ` [RFC PATCH v2.1 07/16] btrfs-progs: fsck: Introduce function to check shared " Qu Wenruo
2016-05-17 9:38 ` [RFC PATCH v2.1 08/16] btrfs-progs: fsck: Introduce function to check an extent Qu Wenruo
2016-05-17 9:38 ` [RFC PATCH v2.1 09/16] btrfs-progs: fsck: Introduce function to check dev extent item Qu Wenruo
2016-05-17 9:38 ` [RFC PATCH v2.1 10/16] btrfs-progs: fsck: Introduce function to check dev used space Qu Wenruo
2016-05-17 9:38 ` [RFC PATCH v2.1 11/16] btrfs-progs: fsck: Introduce function to check block group item Qu Wenruo
2016-05-17 9:38 ` [RFC PATCH v2.1 12/16] btrfs-progs: fsck: Introduce function to check chunk item Qu Wenruo
2016-05-17 9:38 ` [RFC PATCH v2.1 13/16] btrfs-progs: fsck: Introduce hub function for later fsck Qu Wenruo
2016-05-17 9:38 ` [RFC PATCH v2.1 14/16] btrfs-progs: fsck: Introduce function to speed up fs tree check Qu Wenruo
2016-05-17 9:38 ` [RFC PATCH v2.1 15/16] btrfs-progs: fsck: Introduce traversal function for fsck Qu Wenruo
2016-05-17 9:38 ` [RFC PATCH v2.1 16/16] btrfs-progs: fsck: Introduce low memory mode Qu Wenruo
2016-05-17 15:29 ` Josef Bacik
2016-05-18 0:58 ` Qu Wenruo
2016-05-19 14:51 ` David Sterba
2016-05-20 2:33 ` Qu Wenruo
2016-05-23 11:08 ` David Sterba
2016-05-24 3:19 ` Qu Wenruo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1463477930-3925-1-git-send-email-quwenruo@cn.fujitsu.com \
--to=quwenruo@cn.fujitsu.com \
--cc=dsterba@suse.cz \
--cc=jbacik@fb.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).