From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Kernel Dump scanning directory
Date: Fri, 8 May 2015 22:06:10 +0000 (UTC) [thread overview]
Message-ID: <pan$d9931$d653b924$fe7b0555$13f9ab1@cox.net> (raw)
In-Reply-To: D7C742B6-7DD3-49F3-B49A-4C8FD5B97527@plack.net
Anthony Plack posted on Fri, 08 May 2015 16:37:05 -0500 as excerpted:
> 30 seconds on a server can be allot of data, and is to small of a time
> span for adequate backups to occur.
> Maybe we need a warning at the top of the BTRFS page that it is highly
> likely, if BTRFS crashes and the transactions get corrupt, that you WILL
> loose at a minimum the last 30 seconds of your data and maybe more.
Note that commit time has been a mount-time option for a number of kernel
releases, now. It's 30 seconds by default, and IMO that's a reasonable
compromise, but it /is/ an option.
In general I agree, however, particularly about the stability, which
simply isn't as good as some would make it, ATM[1], tho Hugo does make a
valid point, there's another bug triggering the (current) problem, and
getting that rooted out is critical, regardless of where this more
general debate goes.
---
[1] And unfortunately, that lack of very visible stability warning, as
they've all been removed, is causing people to rely on btrfs without
backups, that really should either have backups, or if they really /must/
play without backups, they really /should/ be on something other than
btrfs at this point.
Tho FWIW I think the unstated thinking is that the warnings were scaring
away the broader level of testing that btrfs needs at this point, with
the thought being chicken and egg, we wouldn't get the needed testing
with the warnings, and the warnings couldn't be truthfully taken away
without that needed testing and followup, so I think someone decided it
was time to fudge a bit, at least to the extent of arranging for the
absence of warnings that /were/ there previously, thus allowing deception
by omission for those who simply don't look close enough at the small-
print when they choose their filesystem, as well as not realizing that
even on "stable" filesystems let alone something still not entirely
stable like btrfs, lack of a backup really does state by action that you
simply don't care about the data, and prefer to risk its potential loss
over the certain time and opportunity cost of actually doing/testing the
backups.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2015-05-08 22:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-06 21:56 Kernel Dump scanning directory Anthony Plack
2015-05-07 14:33 ` Anthony Plack
2015-05-07 21:30 ` Anthony Plack
2015-05-08 16:44 ` Anthony Plack
2015-05-08 20:58 ` Duncan
2015-05-08 21:37 ` Anthony Plack
2015-05-08 22:06 ` Duncan [this message]
2015-05-08 22:06 ` Noah Massey
2015-05-08 21:18 ` Hugo Mills
2015-05-08 21:49 ` Anthony Plack
2015-05-08 22:37 ` Hugo Mills
2015-05-11 17:30 ` Anthony Plack
2015-05-12 6:33 ` Duncan
2015-05-08 22:01 ` Kernel Dump scanning directory - New Scary Issue Anthony Plack
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='pan$d9931$d653b924$fe7b0555$13f9ab1@cox.net' \
--to=1i5t5.duncan@cox.net \
--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).