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
next prev parent 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