Re: Can't remove empty directory after kernel panic, no errors in dmesg

[Duncan <1i5t5.duncan@cox.net>]

Niklas Schnelle posted on Sat, 07 Dec 2013 12:37:05 +0000 as excerpted:

> root 470 inode 60984 errors 200
> root 470 inode 62463 errors 200

Three quick things to note:

1) As another thread pointed out recently, that's not 200 errors, but an 
error type bitmask, with the 0x200 bit set.  Based on that other thread 
(I'm not a dev and haven't actually looked myself), there's comments/
varnames in the code (unfortunately only, no non-dev admin-level 
documentation anywhere that I know of) saying what each bitflag 
represents.

2) I had meant to mention earlier but forgot:  As announced on this list 
IIRC shortly after the kernel 3.12 release, btrfs-progs is now versioned 
similar to the kernel and will follow a similar release schedule as long 
as the level of new code warrants (possibly skipping kernel versions here 
and there as the code ultimately stabilizes and churn slows down), with 
the first release following that version scheme being 3.12.

Your reported version number is v0.20-rc1, no git commit snapshot 
indication, and IIRC that was released late last year, so it's about a 
year old now.  You may wish to try something a bit newer, to match your 
3.13-release-candidate kernel version.  There have been a number of fixes 
since v0.20-rc1 (including btrfsck being made part of the main btrfs 
command now, as btrfs check) and it's just possible a current version may 
fix your issues.

3) You asked in what might have been a private mail as I didn't see it 
hit the list, what liveCD, etc, to use, since it's a rootfs btrfs that 
you're working with.  The list mail I'm replying to says you tried a live 
stick (doesn't say the version), so you've worked around that to some 
extent, but as a more general followup based on the multiple independent 
btrfs partitions scheme I use that I mentioned earlier in the thread...

One of the best setups I've come up with over a decade's worth of 
experience here is, as I said, multiple independent partitions, with the 
first level backup actually on an identically sized partition on the same 
physical device.

So I have a working rootfs and a rootbak, identically sized independent 
partitions, with snapshot copy of the working root taken at a point I'm 
comfortable that it's stable.  There's further copies on other (also 
bootable) media, on reiserfs in case the after all still under heavy 
development btrfs blows up both my working root and primary backup.

That very nicely solves the whole rescue disk issue, since I effectively 
have my entire installed and configured system, *NOT* just a few rescue 
tools, as a snapshot taken when I did the backup, as ready to go now as 
it was when I did the backup, even if it's slightly out of date now and 
would need an update to bring it current.  That means all documentation, 
a fully configured X and kde install, media players so I can listen to 
music while I'm fixing the system, it's all there and ready to go, just 
as it was at the time I did the backup.

(I actually keep multiple fstab layouts around too, maintained with a 
script so I can update one and run the script to update the others, with 
fstab itself actually being a symlink to the active one, making selecting 
an fstab layout as easy as updating a symlink from single-user-mode.)

-- 
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