Debian Bug report logs - #703211
btrfs-tools: btrfsck doesn't do anything by default and doesn't document command line options

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Russell Coker <russell@coker.com.au>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: btrfs-tools: btrfsck doesn't do anything by default and doesn't document command line options

Date: Sun, 17 Mar 2013 11:30:25 +1100

Package: btrfs-tools
Version: 0.19+20120328-7.1
Severity: normal
Tags: upstream

By default btrfsck doesn't write any changes to disk.  This isn't documented in
the man page or the help output when btrfsck is run.

Obviously the operation of the program needs to be documented.  Also I think
that when it is run without a parameter such as --repair then when it completes
it should display a message such as "no changes made to disk as --repair was
not used" so that the user isn't left wondering why their filesystem is still
broken after btrfsck has been run.

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (350, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages btrfs-tools depends on:
ii  e2fslibs    1.42.5-1
ii  libc6       2.13-38
ii  libcomerr2  1.42.5-1
ii  libuuid1    2.20.1-5.1.0
ii  zlib1g      1:1.2.7.dfsg-13

btrfs-tools recommends no packages.

btrfs-tools suggests no packages.

-- no debconf information

Message #10 received at 703211@bugs.debian.org (full text, mbox, reply):

From: Julius Seemayer <debian@yeeer.net>

To: 703211@bugs.debian.org

Subject: btrfs-tools: btrfsck doesn't do anything by default and doesn't document command line options

Date: Mon, 17 Feb 2014 03:09:21 +0100

tag 703211 + confirmed
thanks

Hi,


I  can confirm this bug.  The man page is nearly unusable and doesn't document
any  parameters,  even  though the btrfsck binary accepts them.  (Although the
argument handling is broken in Wheezy, see #739246.)


Cheers,

	Julius

Message #17 received at 703211-done@bugs.debian.org (full text, mbox, reply):

From: Adam Borowski <kilobyte@angband.pl>

To: 703211-done@bugs.debian.org

Subject: long since documented

Date: Sun, 16 Jun 2019 14:35:41 +0200

[I'm taking over the package, and triaging old bugs.  Sorry that you did not
receive a response earlier -- the bug is long since fixed.]

> By default btrfsck doesn't write any changes to disk.  This isn't documented in
> the man page or the help output when btrfsck is run.

The man page says early on:

# By default, btrfs check will not modify the device but you can reaffirm
# that by the option --readonly.
[...]
# Warning
# Do not use --repair unless you are advised to do so by a developer or an
# experienced user, and then only after having accepted that no fsck
# successfully repair all types of filesystem corruption.  Eg. some other
# software or hardware bugs can fatally damage a volume.

Which, I believe, documents this adequately.

> Obviously the operation of the program needs to be documented.  Also I think
> that when it is run without a parameter such as --repair then when it completes
> it should display a message such as "no changes made to disk as --repair was
> not used" so that the user isn't left wondering why their filesystem is still
> broken after btrfsck has been run.

The name "btrfsck" is deprecated since ages.  The new name, "btrfs check"
sounds way more obvious that its primary mode is to check.

Generally, if a modern filesystem is in the need of repair, you are already
in deep shit, and it's mostly a hail mary attempt at data recovery.  For
which, there are better ways than to modify the broken filesystem in-place.
(As opposed to filesystems from the previous millenium, which required
repair after every unclean shutdown.)

Judging from reports on IRC and the mailing list, around 90% of broken
filesystems are caused by dodgy hardware (memory, cables, controllers) thus
"repair" would lead to reoccurence of data loss a short time later.

Btrfs in particular is very "good" at finding dodgy hardware (esp. memory),
and terrible at ignoring corruption if you wish to read damaged data anyway.
On the other hand, it goes a long way towards detecting corruption (no other
in-mainline filesystem has data checksums), and provides nice ways for cheap
backups.

Thus, the design for "btrfs check" to do no modifications seems sound to me.


If you disagree that the documentation is enough, please says o.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Don't be racist.  White, amber or black, all beers should
⣾⠁⢠⠒⠀⣿⡁ be judged based solely on their merits.  Heck, even if
⢿⡄⠘⠷⠚⠋  occasionally a cider applies for a beer's job, why not?
⠈⠳⣄⠀⠀⠀⠀ On the other hand, corpo lager is not a race.

Send a report that this bug log contains spam.