Re: Filesystem won't mount (open_ctree failed) or repair (BUG_ON)

[Chris Murphy]

On Fri, Jun 9, 2017 at 1:57 PM, Hugo Mills  wrote:
> On Fri, Jun 09, 2017 at 09:12:16PM +0200, Koen Kooi wrote:
>> Hi,
>>
>> Today the kernel got wedged during shutdown (4.11.x tends to do that, haven't
>> debugged) and I pressed the reset button. The next boot btrfs won't mount:
>>
>> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): parent transid verify 
>> failed on 5840011722752 wanted 170755 found 170832
>> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): parent transid verify 
>> failed on 5840011722752 wanted 170755 found 170832
>> [Fri Jun  9 20:46:07 2017] BTRFS error (device md0): failed to read block 
>> groups: -5
>> [Fri Jun  9 20:46:08 2017] BTRFS error (device md0): open_ctree failed
>
>With a transid failure on mount, about the only thing that's likely
> to work is mounting with -o usebackuproot. If that doesn't work, then
> a rebuild of the FS is almost certainly needed.

Weird that it wants almost 80 generations back from what's found.
Sounds like betrayal somewhere...

I'd say take a btrfs-image and put it up somewhere and also file a
bug. The fsck should not crash.

What are these showing?
# btrfs insp dump-s -f /dev/
# btrfs rescue super /dev/
# btrfs-find-root /dev/



-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

eBPF tracing Btrfs performance

[Chris Murphy]

Ran into this:
http://www.brendangregg.com/ebpf.html

And then found this:
https://github.com/iovisor/bcc/blob/master/tools/btrfsslower.py


Anyone given it a shot? This is in the regular Fedora repo, so 'dnf
install bcc kernel-devel' will do it. I'm running into a segmentation
fault, most likely because I'm on a pre-release of Fedrao 26. But it
looks kinda interesting.


-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs native encryption

[Anand Jain]

 dealing with inheritance of
encryption when making snapshots, and dealing with reflinks.


 Right. To address this, there is a proposal to bring encryption down 
to the extent level, it solves these limitations.


Thanks, Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs native encryption

[Anand Jain]

  For phase-1 the idea was to make btrfs encryption inline with 
fs/crytpo which wasn't available when it started, so certainly there are 
things which could straight away filter out after its known what went 
into fs/crypto from ext4, especially the cryptography part.


 Now, 4.10 kernel based, btrfs encryption using fs/crypto is here [1]. 
It has under gone limited testing by me and yet to arrive at a 
conclusion on the file-name encryption, though its discussions are here 
[2], and patches aren't sent out to the BTRFS ML yet.



[1] Phase-1.
  Progs: https://github.com/asj/btrfs-progs-fscryptv1
  Kernel: https://github.com/asj/linux-btrfs-fscryptv1

[2] File name encryption discussions are here:
 (I don't see some of the emails I have in the google search, so 
instead I have listed the subject for your search).

   On the ext4 ML:
Sub: fs/crypto: file-name encryption, optional ?
Sub: fs/crypto: root read-access without key

Thanks, Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Questions about how BtrFS works.

[Hy Che]

Hello everyone,
My name is Hy (ugen on freenode), I am a student attending GSoC for
Haiku[1]. Because I have a project that support write features for
BtrFS[2], there are some questions, since the documents on wiki are
not enough so I have to ask here.

1. Where can I find to read a complete btree manipulations in detail
(split, insert, etc) for BtrFS except the code base ?  I need to get
the idea first.

2. About the reference,  " ...with a refcount associated to each tree
node but stored in an ad-hoc free map structure ... " - wikipedia.
What is a free map structure, and where does it stored ?

3. How BtrFS allocate block and extent when cow-ed ? As I tested after
making a new file, the root tree root, extent root and csum root move
forward 65536 bytes, the fs root move 49152 bytes and the data extent
is allocated next to the previous one. Where those numbers come from ?
Is data extent is cow-ed ? I see it doesn't because extent-item still
contains the old offset.

4. How BtrFS handle transactions ?
Correctly me if I'm wrong, the transaction collect all requests in 30
seconds and then write back to disk. The transid increments when new
request appeared and genid is asigned to this one.

5. Why there is unused space (100 bytes) at the end of each node ?
6. How does BtrFS calculate checksum ?


[1]: About Haiku: www.haiku-os.org
[2]: My project info on GSoC:
https://summerofcode.withgoogle.com/projects/4749427110576128

Thanks,
Hy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] Btrfs

[Chris Mason]

Hi Linus,

My for-linus-4.12 branch has some fixes that Dave Sterba collected:

git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git 
for-linus-4.12

We've been hitting an early enospc problem on production machines that
Omar tracked down to an old int->u64 mistake.  I waited a bit on
this pull to make sure it was really the problem from production,
but it's on ~2100 hosts now and I think we're good.

Omar also noticed a commit in the queue would make new early ENOSPC
problems.  I pulled that out for now, which is why the top three commits
are younger than the rest.

Otherwise these are all fixes, some explaining very old bugs that we've
been poking at for a while.

Jeff Mahoney (2) commits (+4/-3):
btrfs: fix race with relocation recovery and fs_root setup (+3/-3)
btrfs: fix memory leak in update_space_info failure path (+1/-0)

Liu Bo (1) commits (+1/-1):
Btrfs: clear EXTENT_DEFRAG bits in finish_ordered_io

Colin Ian King (1) commits (+1/-1):
btrfs: fix incorrect error return ret being passed to mapping_set_error

Omar Sandoval (1) commits (+2/-2):
Btrfs: fix delalloc accounting leak caused by u32 overflow

Qu Wenruo (1) commits (+122/-2):
btrfs: fiemap: Cache and merge fiemap extent before submit it to user

David Sterba (1) commits (+2/-2):
btrfs: use correct types for page indices in btrfs_page_exists_in_range

Jan Kara (1) commits (+6/-4):
btrfs: Make flush bios explicitely sync

Su Yue (1) commits (+1/-1):
btrfs: tree-log.c: Wrong printk information about namelen

Total: (9) commits (+139/-16)

 fs/btrfs/ctree.h   |   4 +-
 fs/btrfs/dir-item.c|   2 +-
 fs/btrfs/disk-io.c |  10 ++--
 fs/btrfs/extent-tree.c |   7 +--
 fs/btrfs/extent_io.c   | 126 +++--
 fs/btrfs/inode.c   |   6 +--
 6 files changed, 139 insertions(+), 16 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html