Re: Loss of connection to Half of the drives

On Fri, Dec 25, 2015, 11:28 PM David Schulz wrote: > > > I mentioned the btrfs rescue command with the mismatching fsid message. > After dd'ing /dev/zero to all but the boot drive, the fsid mismatch went > away, but the tool still segfaults on the filesystem after losing

Re: btrfs problems on new file system

On Sat, Dec 26, 2015 at 4:38 AM, wrote: > Duncan <1i5t5.dun...@cox.net> wrote: > >> covici posted on Sat, 26 Dec 2015 02:29:11 -0500 as excerpted: >> >> > Chris Murphy wrote: >> > >> >> If you can post the entire dmesg somewhere that'd be useful.

Re: btrfs problems on new file system

Chris Murphy wrote: > On Sat, Dec 26, 2015 at 4:38 AM, wrote: > > Duncan <1i5t5.dun...@cox.net> wrote: > > > >> covici posted on Sat, 26 Dec 2015 02:29:11 -0500 as excerpted: > >> > >> > Chris Murphy wrote: > >> > > >>

Re: btrfs problems on new file system

On Sat, Dec 26, 2015 at 12:22 PM, wrote: > Chris Murphy wrote: > >> On Sat, Dec 26, 2015 at 4:38 AM, wrote: >> > Duncan <1i5t5.dun...@cox.net> wrote: >> > >> >> covici posted on Sat, 26 Dec 2015 02:29:11 -0500 as

Re: btrfs problems on new file system

On Sat, Dec 26, 2015 at 1:02 PM, wrote: > Chris Murphy wrote: > >> On Sat, Dec 26, 2015 at 12:22 PM, wrote: >> > Chris Murphy wrote: >> > >> >> On Sat, Dec 26, 2015 at 4:38 AM,

Re: Timeouts copying large files to a Samba server with Btrfs

That does not look good. See if you can find something in the samba logs on the server. Look for messages about long running VFS operations and/or client disconnecting wile a file is open for writing. The CIFS/SMB protocol has hard real-time requirements in the windows client redirector which

Re: btrfs problems on new file system

Chris Murphy wrote: > On Sat, Dec 26, 2015 at 12:22 PM, wrote: > > Chris Murphy wrote: > > > >> On Sat, Dec 26, 2015 at 4:38 AM, wrote: > >> > Duncan <1i5t5.dun...@cox.net> wrote: > >> > > >> >>

Re: Timeouts copying large files to a Samba server with Btrfs

Hello, My guess is that the Samba server process submits too much queued buffers at once to be written to disk, then blocks on waiting for this, and the whole operation ends up taking so long, that it doesn't get back to the client in time. I've seen something similar. I could reproduce it

Re: btrfs problems on new file system

Duncan <1i5t5.dun...@cox.net> wrote: > covici posted on Sat, 26 Dec 2015 02:29:11 -0500 as excerpted: > > > Chris Murphy wrote: > > > >> If you can post the entire dmesg somewhere that'd be useful. MUAs tend > >> to wrap that text and make it unreadable on list. I

Re: btrfs problems on new file system

covici posted on Sat, 26 Dec 2015 02:29:11 -0500 as excerpted: > Chris Murphy wrote: > >> If you can post the entire dmesg somewhere that'd be useful. MUAs tend >> to wrap that text and make it unreadable on list. I think the problems >> with your volume happened before

[PATCH] btrfs: cleanup unusable parameters from ctree.h

Cleanup of ununsed parameters in btrfs_header_chunk_tree_uuid, btrfs_leaf_data and btrfs_defrag_cancelled Signed-off-by: Caio Lima --- fs/btrfs/ctree.c | 46 +++--- fs/btrfs/ctree.h | 10 +- fs/btrfs/disk-io.c

Re: Ideas on unified real-ro mount option across all filesystems

On Thu, Dec 24, 2015 at 10:22:31AM +1100, Stewart Smith wrote: > Eric Sandeen writes: > >> 3) A lot of user even don't now mount ro can still modify device > >>Yes, I didn't know this point until I checked the log replay code of > >>btrfs. > >>Adding such mount

Re: [PATCH] improve documentation of snapshot unaware defrag

On Sun, 2015-12-27 at 04:03 +0100, Christoph Anton Mitterer wrote: > -WARNING: defragmenting with kernels up to 2.6.37 will unlink COW-ed Perhaps someone can also check the above. I was looking through the git history, but, couldn't find anything wrt 2.6.37... The commit's I've basically searched

Re: [BUG?] btrfs scrub -d doesn't scan all devices

Christoph Anton Mitterer posted on Sun, 27 Dec 2015 04:38:56 +0100 as excerpted: > I've just noted the following behaviour: > > # btrfs scrub start -Bdr / > scrub device /dev/sda2 (id 1) done > scrub started at Sun Dec 27 01:59:05 2015 > and finished after 00:04:04 > total

[BUG?] btrfs scrub -d doesn't scan all devices

Hey. I've just noted the following behaviour: # btrfs scrub start -Bdr / scrub device /dev/sda2 (id 1) done scrub started at Sun Dec 27 01:59:05 2015 and finished after 00:04:04 total bytes scrubbed: 29.39GiB with 0 errors scrub device /dev/sdb2 (id 2) done scrub started

Re: Btrfs Check - "type mismatch with chunk"

On Thu, 2015-12-24 at 23:41 +, Duncan wrote: > as the patch is in the userspace  4.3.1 you're running. I don't think this is the case. The commit was b08a740d7b797d870cbc3691b1291290d0815998 and AFAICT, it's not included in any release yet. 4.3.1 was from Nov 16th, the above commit was from

Re: [PATCH] improve documentation of snapshot unaware defrag

Christoph Anton Mitterer posted on Sun, 27 Dec 2015 04:03:27 +0100 as excerpted: [Rewrapped here but all added lines.] > +WARNING: Defragmenting with Linux kernel versions < 3.9 or ≥ 3.14-rc2 > as well as > +with Linux stable kernel versions ≥ 3.10.31, ≥ 3.12.12 or ≥ > 3.13.4 will break up >