public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Undelete files
Date: Wed, 2 Jan 2019 02:48:28 +0000 (UTC)	[thread overview]
Message-ID: <pan$dcdef$678b9b0d$9f8492f4$6519613a@cox.net> (raw)
In-Reply-To: CADXXWGw-8uDqeXSdjkwmBfK4-OiN5Wk7q3k2yPvzFiF3uzYmzQ@mail.gmail.com

Jesse Emeth posted on Sun, 30 Dec 2018 16:58:12 +0800 as excerpted:

> Hi Duncan
> 
> The backup is irrelevant in this case. I have a backup of this
> particular problem.
> I've had BTRFS on my OS system blow up several times.
> There are several snapshots of this within the subvolume.
> However, such snapshots are not helpful unless they are snapshots
> copied elsewhere with restore/rsync etc.

How can backups and snapshots not be helpful in terms of a problem where 
you'd be using undelete?  Undelete implies the filesystem is fine and 
that you're just trying to get a few files that you mistakenly deleted 
back, which in fact was the claim, and both backups and snapshots should 
allow you to do just that, get your deleted files back.

> I had spoken to someone expressing my concerns with BTRFS on IRC.
> He wanted me to present this so that such problems could be rectified.
> I also wanted to learn more about BTRFS to see if my determinations
> about its inadequacies were incorrect.
> 
> Thus I want to follow this through to see if what is actually a very
> very small problem related to just a non essential small Firefox cache
> directory can actually be fixed.
> At present this very very small problem brings down the entire volume
> and all subvolumes with no way to mount any of it rw or easily fix the
> issue.
> That is not sane for such a small issue.

That's not a file undelete issue.  That's an entire filesystem issue.  
Quite a different beast, and not one that I directly addressed in my 
reply (altho the data value vs. backups stuff applies to fat-fingering 
such as mistaken deletes, filesystem problems, hardware problems, and 
natural disasters, all four), because both the title and the content 
suggested a file undelete issue, which /was/ addressed.

-- 
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:[~2019-01-02  2:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20181229225140.08d397fb@ws>
2018-12-30  8:58 ` Undelete files Jesse Emeth
2019-01-02  2:48   ` Duncan [this message]
2018-12-29 22:22 Adrian Bastholm
2018-12-30  4:11 ` Duncan
2018-12-30  5:44   ` Duncan
  -- strict thread matches above, loose matches on Subject: below --
2018-08-04 16:47 undelete files Laurent Lauden
2018-12-17 11:38 ` Massimo B.

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$dcdef$678b9b0d$9f8492f4$6519613a@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