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: BTRFS critical (device dm-0): invalid dir item name len: 45389
Date: Thu, 4 Sep 2014 22:26:40 +0000 (UTC)	[thread overview]
Message-ID: <pan$680f3$c4143e4$b1f456fa$d9f8eac0@cox.net> (raw)
In-Reply-To: CANg_oxzsAAV3S-Qc=mz0GTVXnPFrQ43riNXVbtT4Wjqtwsbo2A@mail.gmail.com

john terragon posted on Thu, 04 Sep 2014 15:03:04 +0200 as excerpted:

> Some more details about this problem:
> 
> -the directory involved is
> /lib/modules/3.17.0-rc3-cu3/kernel/drivers/iio/gyro -in that dir there
> should be kernel object named hid-sensor-gyro-3d.ko but there's
>  no trace of it
> -that dir cannot be removed or overwritten. rm -rf fails saying that the
> dir cannot be
>  removed because it's not empty (?, even with -rf ?) and trying to
> reinstall the .deb
>  package for that kernel image (thus overwriting that dir) ends up in a
>  segfault
> 
> The only workaround is to mv that dir (well, I simply mv the whole
> 3.17.0-rc3-cu3 dir but it should work also for the gyro subdir) and
> reinstall the deb package.
> 
> So, it's pretty serious because there's actual loss of data (even though
> I was lucky I just lost a ko I don't use).

I'd do a btrfs check (read-only without --repair or other switch) to see 
what it came up with, then if it looked reasonable, ensure my backups 
were fresh and do a btrfs check --repair.

If it fails or makes the problem worse, you can then mkfs and restore 
from the backups.

Meanwhile, nobody sane would keep valuable data on a raid0 (any raid0, 
btrfs or not) without backups anyway, as it's simply too risky, so by 
definition the problem /cannot/ be "pretty serious.  By definition, 
what's stored on a raid0 is more or less throw-away data that can either 
be recomputed or refetched from backup (which might be the net), or is 
simply tmp/cache in the first place.  So losing it can never be defined 
as "pretty serious", unless of course you're using raid0 for valuable 
data it was never intended, and don't keep current backups, which as I 
said for any responsible sysadmin (and with that I include every home 
user responsible for their own system, it's a responsibility taken too 
lightly by many) working with raid0 is insanity.

So if you're characterizing any potential loss of data on any sort of  
raid0 (btrfs or otherwise) as "pretty serious", I *STRONGLY* recommend 
that you reconsider using raid0 in the first place, because loss of 
ANYTHING, upto and including EVERYTHING on a raid0, by definition cannot 
be "pretty serious" or you're simply using it wrong.  And if you're doing 
a mkfs and restore from backup, that's the perfect opportunity to 
reconsider and choose something more appropriate. =:^)

-- 
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:[~2014-09-04 22:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-04  5:30 BTRFS critical (device dm-0): invalid dir item name len: 45389 john terragon
2014-09-04 13:03 ` john terragon
2014-09-04 22:26   ` Duncan [this message]
2014-09-05  0:20     ` john terragon
2014-09-05  1:41       ` Chris Murphy
2014-09-05  2:07         ` Duncan
2014-09-05  3:20           ` Chris Murphy
2014-09-05  2:05       ` Duncan
2014-09-04 22:06 ` 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$680f3$c4143e4$b1f456fa$d9f8eac0@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).