linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).