Your message dated Sun, 16 Jun 2019 14:35:41 +0200
with message-id <[email protected]>
and subject line long since documented
has caused the Debian Bug report #703211,
regarding btrfs-tools: btrfsck doesn't do anything by default and doesn't
document command line options
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
703211: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703211
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
[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.
--- End Message ---
