From: Hugo Mills <hugo@carfax.org.uk>
To: Ivan Sizov <sivan606@gmail.com>
Cc: Chris Murphy <lists@colorremedies.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Strange behavior after "rm -rf //"
Date: Mon, 8 Aug 2016 18:52:37 +0000 [thread overview]
Message-ID: <20160808185237.GA9644@carfax.org.uk> (raw)
In-Reply-To: <CAMG9ccwqnK63sbcF79VndBMitvFjX6pHPCU9YrrZcwEdiQxY5w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1951 bytes --]
On Mon, Aug 08, 2016 at 09:38:28PM +0300, Ivan Sizov wrote:
> 2016-08-08 20:13 GMT+03:00 Chris Murphy <lists@colorremedies.com>:
> > Just a wild guess, the deletions may be in the tree log and haven't
> > been applied to the other trees (fs tree, extent tree, etc). So yes
> > I'd expect they get deleted on a rw mount.
> >
> > This is what kernel? Because kernel 4.6 offers mount option
> > "nologreplay" which suggests even if you do mount -r that log replay
> > happens, so you shouldn't see these deleted files unless you mount ro
> > *and* use nologreplay mount option.
>
> Live USB has kernel 4.5.7. Maybe I should try to run "btrfs rescue
> zero-log" and then mount RW? Will the files safe in that case?
>
> > Anyway, even 5 seconds of rm -rf damages too much. If you don't have
> > recent snapshots then it's not sanely salvageable, just reinstall.
>
> As I could see, almost all the "deleted" files are present. Certainly,
> I'll make an rsync diff between two-week-ago snapshot and the current
> FS state. But it will better if in-place recover without backup is
> possible.
>
> P.S. IMHO, log replay by default is a quite dangerous thing. I didn't
> know about that change and I could lose all files if the live USB had
> 4.6 kernel))
Log reply on mount has _always_ been the default, and should remain
so. It gives you the expected semantics after a power loss: all th
efiles that you'd written up to the point of the power loss actually
appear afterwards. (If this didn't happen, you could lose up to 30s of
writes from before the crash).
It's only very recently that there's been an option to prevent it,
which is useful in a limited number of cases (such as trying to
undelete a file, which is not really a supported operation in any
case).
Hugo.
--
Hugo Mills | "I lost my leg in 1942. Some bastard stole it in a
hugo@... carfax.org.uk | pub in Pimlico."
http://carfax.org.uk/ |
PGP: E2AB1DE4 |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2016-08-08 18:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-08 16:30 Strange behavior after "rm -rf //" Ivan Sizov
2016-08-08 17:13 ` Chris Murphy
2016-08-08 18:38 ` Ivan Sizov
2016-08-08 18:52 ` Hugo Mills [this message]
2016-08-08 19:00 ` Ivan Sizov
2016-08-09 17:10 ` Chris Murphy
2016-08-09 20:30 ` Duncan
2016-08-21 17:54 ` Ivan Sizov
2016-08-08 19:02 ` Duncan
2016-08-09 23:24 ` Christian Kujau
2016-08-12 3:08 ` Russell Coker
2016-08-12 6:15 ` Christian Kujau
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=20160808185237.GA9644@carfax.org.uk \
--to=hugo@carfax.org.uk \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=sivan606@gmail.com \
/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).