Re: Bad magic on superblock on /dev/sda at 65536

First superblock is zero-ed and its not some random corruption, most probably someone else other than btrfs used the disk when it was unmounted? Or if the partition (if any) was changed? or if its a SAN storge hope the LUN wasn't recreated at the storage end. Thanks, Anand On 04/07/2018

Re: Bad magic on superblock on /dev/sda at 65536

On 7 April 2018 at 10:56, Qu Wenruo wrote: > > > On 2018年04月07日 08:35, Ben Parsons wrote: >>> btrfs inspect-internal dump-super -Ffa /path >> >> superblock: bytenr=65536, device=/dev/sda >> - >> csum_type0

Re: Bad magic on superblock on /dev/sda at 65536

On 2018年04月07日 08:35, Ben Parsons wrote: >> btrfs inspect-internal dump-super -Ffa /path > > superblock: bytenr=65536, device=/dev/sda > - > csum_type0 (crc32c) > csum_size4 > csum0x [DON'T MATCH] >

Re: Bad magic on superblock on /dev/sda at 65536

>btrfs inspect-internal dump-super -Ffa /path superblock: bytenr=65536, device=/dev/sda - csum_type0 (crc32c) csum_size4 csum0x [DON'T MATCH] bytenr0 flags0x0 magic

Re: Bad magic on superblock on /dev/sda at 65536

On 2018年04月07日 01:03, David Sterba wrote: > On Fri, Apr 06, 2018 at 11:32:34PM +1000, Ben Parsons wrote: >> Hi, >> >> I just had an unexpected restart and now my btrfs pool wont mount. >> The error on mount is: >> >> "ERROR: unsupported checksum algorithm 41700" >> >> and when running >> >>

Re: [PATCH v2 2/2] btrfs: Validate child tree block's level and first key

On 2018年04月07日 01:07, David Sterba wrote: > On Mon, Apr 02, 2018 at 06:47:32PM +0800, Qu Wenruo wrote: >> On 2018年03月28日 23:49, David Sterba wrote: >>> On Tue, Mar 27, 2018 at 08:44:19PM +0800, Qu Wenruo wrote: We have several reports about node pointer points to incorrect child tree

Re: [PATCH 08/16] btrfs: add sanity check when resuming balance after mount

Hi, [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 16.7330) The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92, v4.4.126. v4.16: Build OK! v4.15.15:

Re: [PATCH] bitmap: fix memset optimization on big-endian systems

Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: 2a98dc028f91 include/linux/bitmap.h: turn bitmap_set and bitmap_clear into memset when possible. The bot has also determined it's probably a bug fixing patch. (score: 65.4067)

Re: [PATCH 07/16] btrfs: add proper safety check before resuming dev-replace

Hi, [This is an automated email] This commit has been processed by the -stable helper bot and determined to be a high probability candidate for -stable trees. (score: 34.4419) The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92, v4.4.126. v4.16: Build OK! v4.15.15:

Re: [PATCH] Btrfs: do not abort transaction when failing to insert hole extent

On Fri, Apr 6, 2018 at 6:21 AM, David Sterba wrote: > On Thu, Apr 05, 2018 at 11:58:16AM -0700, Liu Bo wrote: >> On Thu, Apr 5, 2018 at 9:48 AM, David Sterba wrote: >> > On Sat, Mar 31, 2018 at 06:11:55AM +0800, Liu Bo wrote: >> >> This is running in a typical

Re: [PATCH v2 2/2] btrfs: Validate child tree block's level and first key

On Mon, Apr 02, 2018 at 06:47:32PM +0800, Qu Wenruo wrote: > On 2018年03月28日 23:49, David Sterba wrote: > > On Tue, Mar 27, 2018 at 08:44:19PM +0800, Qu Wenruo wrote: > >> We have several reports about node pointer points to incorrect child > >> tree blocks, which could have even wrong owner and

Re: Bad magic on superblock on /dev/sda at 65536

On Fri, Apr 06, 2018 at 11:32:34PM +1000, Ben Parsons wrote: > Hi, > > I just had an unexpected restart and now my btrfs pool wont mount. > The error on mount is: > > "ERROR: unsupported checksum algorithm 41700" > > and when running > > btrfs inspect-internal dump-super /dev/sda >

Re: Bad magic on superblock on /dev/sda at 65536

On 6.04.2018 16:32, Ben Parsons wrote: > Hi, > > I just had an unexpected restart and now my btrfs pool wont mount. > The error on mount is: > > "ERROR: unsupported checksum algorithm 41700" > > and when running > > btrfs inspect-internal dump-super /dev/sda > ERROR: bad magic

Btrfs progs release 4.16

Hi, btrfs-progs version 4.16 have been released. This version brings the new library that should help applications to use the btrfs functionality in a more convenient way than plain ioctls. And has python bindings. The rest are bugfixes and small enhancements. The library is hosted in the progs

Bad magic on superblock on /dev/sda at 65536

Hi, I just had an unexpected restart and now my btrfs pool wont mount. The error on mount is: "ERROR: unsupported checksum algorithm 41700" and when running btrfs inspect-internal dump-super /dev/sda ERROR: bad magic on superblock on /dev/sda at 65536 I saw a thread in the mailing

Re: [PATCH v3 2/3] btrfs: Allow rmdir(2) to delete a subvolume

On Fri, Mar 30, 2018 at 03:16:47PM +0900, Misono Tomohiro wrote: > This patch changes the behavior of rmdir(2) to allow it to delete > an empty subvolume by default, unless it is not a default subvolume > and send is not in progress. > > New function btrfs_delete_subvolume() is almost equal to

Re: [PATCH] Btrfs: fix loss of prealloc extents past i_size after fsync log replay

On Thu, Apr 05, 2018 at 10:55:12PM +0100, fdman...@kernel.org wrote: > From: Filipe Manana > > Currently if we allocate extents beyond an inode's i_size (through the > fallocate system call) and then fsync the file, we log the extents but > after a power failure we replay them

Re: [PATCH] Btrfs: do not abort transaction when failing to insert hole extent

On Thu, Apr 05, 2018 at 11:58:16AM -0700, Liu Bo wrote: > On Thu, Apr 5, 2018 at 9:48 AM, David Sterba wrote: > > On Sat, Mar 31, 2018 at 06:11:55AM +0800, Liu Bo wrote: > >> This is running in a typical write path, not inside a critical path > >> where we have to abort the

Re: [PATCH] Btrfs: clean up resources during umount after trans is aborted

On Thu, Apr 05, 2018 at 11:45:55AM -0700, Liu Bo wrote: > On Thu, Apr 5, 2018 at 9:11 AM, David Sterba wrote: > > On Sat, Mar 31, 2018 at 06:11:56AM +0800, Liu Bo wrote: > >> Currently if some fatal errors occur, like all IO get -EIO, resources > >> would be cleaned up when > >>

Re: [PATCH] btrfs-progs: mkfs rootdir: use lgetxattr() not to follow a symbolic link

On Mon, Apr 02, 2018 at 10:59:31AM +0900, Misono Tomohiro wrote: > mkfs-test 016 "rootdir-bad-symbolic-link" fails when selinux is enabled. > This is because add_xattr_item() uses getxattr() and tries to follow a > bad symbolic link for selinux item, which causes ENOENT error. > > The line above

Re: [PATCH] btrfs-progs: build: Do not use cp -a to install files

On Wed, Apr 04, 2018 at 04:04:59PM +0200, Peter Kjellerstedt wrote: > Using cp -a to install files will preserve the ownership of the > original files (if possible), which is typically not wanted. E.g., if > the files were built by a normal user, but are being installed by > root, then the

[PATCH] fstests: generic test for fsync after fallocate

From: Filipe Manana Test that fsync operations preserve extents allocated with fallocate(2) that are placed beyond a file's size. This test is motivated by a bug found in btrfs where unwritten extents beyond the inode's i_size were not preserved after a fsync and power

[PATCH] Btrfs: fix loss of prealloc extents past i_size after fsync log replay

From: Filipe Manana Currently if we allocate extents beyond an inode's i_size (through the fallocate system call) and then fsync the file, we log the extents but after a power failure we replay them and then immediately drop them. This behaviour happens since about 2009,

[PATCH] btrfs-progs: Use more loose open ctree flags for dump-tree and restore

Corrupted extent tree (either the root node or leaf) can normally block us from open the fs. As normally open_ctree() has the following call chain: __open_ctree_fd() |- btrfs_setup_all_roots() |- btrfs_read_block_groups() And we will search block group items in extent tree. And

[PATCH v2 1/1] btrfs-progs: inspect-dump-tree: Allow '-b|--block' to be specified multiple times

Reuse extent-cache facility to record multiple bytenr so '-b|--block' can be specified multiple times. Despite that, add a sector size alignment check before we try to print a tree block. (Please note that, nodesize alignment check is not suitable here as meta chunk start bytenr could be

[PATCH 0/1] btrfs-progs: dump-tree: allow -b multiple times

Although just one patch, it needs the extent buffer cleanup code as basis, so please fetch it from my github repo: https://github.com/adam900710/btrfs-progs/tree/dump_tree_multi_blocks This patch allow -b to be specified multiple times, and add extra basic check for them. For later enhancement

[PATCH 1/1] btrfs-progs: inspect-dump-tree: Allow '-b|--block' to be specified multiple times

Reuse extent-cache facility to record multiple bytenr so '-b|--block' can be specified multiple times. Despite that, add a sector size alignment check before we try to print a tree block. (Please note that, nodesize alignment check is not suitable here as meta chunk start bytenr could be