From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: BTRFS cannot remove empty directory pretending it is not empty
Date: Tue, 25 Aug 2015 08:37:46 +0000 (UTC) [thread overview]
Message-ID: <pan$d4557$9c42de4e$12e74017$2f692aea@cox.net> (raw)
In-Reply-To: 4755396.RFUxGNmK6p@tethys
Swâmi Petaramesh posted on Tue, 25 Aug 2015 10:18:26 +0200 as excerpted:
> Le vendredi 21 août 2015 11:23:19 Duncan a écrit :
>> So I'd suggest running btrfs check, without --repair, first, and see
>> what it says. If the only reported problems have to do with inode
>> refcounts, then (assuming your backups are current, just in case,
>> admin's rule of backups, if you don't have them, you don't care about
>> losing the data) I'd then go ahead and run it with --repair.
>
> Hi Duncan,
>
> Here's what I get using "btrfs check" on said device. Do you think that
> running it with "--repair" would be beneficial, or risky ?
>
> root@partedmagic:~# btrfs check /dev/VGZ/LINUX
> Checking filesystem on /dev/VGZ/LINUX
> UUID: 13c87f57-3a85-4daf-a4bf-ba777407c169
> checking extents
> checking free space cache
> checking fs roots
> root 267 inode 297 errors 200, dir isize wrong
> root 267 inode 3341 errors 200, dir isize wrong
> root 267 inode 324547 errors 200, dir isize wrong
[and many more errors 200, dir isize wrong, errors flagged, with no other
errors listed]
While cautioning that I'm not a dev, just a btrfs user and list
regular... and I haven't had that particular problem and thus no directly
apropos personal experience here...
The errors 200 flags are reasonably common, and I believe
btrfs check --repair handles them well. I already stressed the admin
rule that no backups means you don't care if it's lost, so with that in
mind, I'd say go ahead with the --repair... as, based on the information
I have, I would were I to see that here.
--
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-08-25 8:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-21 8:19 BTRFS cannot remove empry directory pretending it is not empty Swâmi Petaramesh
2015-08-21 8:47 ` Karsten Heymann
2015-08-21 9:15 ` Swâmi Petaramesh
2015-08-21 9:16 ` Roman Mamedov
2015-08-21 9:45 ` Hugo Mills
2015-08-21 11:23 ` Duncan
2015-08-21 15:39 ` Swâmi Petaramesh
2015-08-21 18:07 ` Duncan
2015-08-25 8:18 ` BTRFS cannot remove empty " Swâmi Petaramesh
2015-08-25 8:37 ` Duncan [this message]
2015-08-25 13:25 ` Swâmi Petaramesh
2015-08-25 14:03 ` Swâmi Petaramesh
2015-08-25 22:29 ` Duncan
2015-08-25 22:38 ` Hugo Mills
[not found] ` <9Aea1r00U2Q6ekd01Aebva>
2015-08-25 23:32 ` Duncan
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$d4557$9c42de4e$12e74017$2f692aea@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).