Re: Drive Replacement

2016-10-21 Thread Peter Becker
if you have >750 GB free you can simply remove one of the drives. btrfs device delete /dev/sd[x] /mnt #power off, replace device btrfs device add /dev/sd[y] /mnt if not you can use an USB-SATA adapter or an eSata-Port and make the following: btrfs device add /dev/sd[y] /mnt btrfs device delete

Re: Drive Replacement

2016-10-21 Thread Hugo Mills
On Sat, Oct 22, 2016 at 09:03:16AM +1100, Gareth Pye wrote: > I've got a BTRFS array that is of mixed size disks: > 2x750G > 3x1.5T > 3x3T > And it's getting fuller than I'd like. The problem is that adding > disks is harder than one would like as the computer only has 8 sata > ports. Is it viable

Drive Replacement

2016-10-21 Thread Gareth Pye
I've got a BTRFS array that is of mixed size disks: 2x750G 3x1.5T 3x3T And it's getting fuller than I'd like. The problem is that adding disks is harder than one would like as the computer only has 8 sata ports. Is it viable to do the following to upgrade one of the disks? A) Take array offline

Re: build error btrfs-progs 4.8.1

2016-10-21 Thread Peter Becker
Generate build-system by: aclocal:aclocal (GNU automake) 1.15 autoconf: autoconf (GNU Autoconf) 2.69 autoheader: autoheader (GNU Autoconf) 2.69 automake: automake (GNU automake) 1.15 Now type './configure' and 'make' to compile. checking for gcc... gcc checking whether the C

build error btrfs-progs 4.8.1

2016-10-21 Thread Peter Becker
$ uname -r 4.8.3-040803-generic $ git remote -v origin git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git (fetch) origin git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git (push) $ git pull Already up-to-date. $ ./autogen.sh ... $ ./configure ... $ make ...

Re: bio linked list corruption.

2016-10-21 Thread Dave Jones
On Fri, Oct 21, 2016 at 04:41:09PM -0400, Josef Bacik wrote: > >> > > >> > btrfs inspect inode 130654 mntpoint > >> > >> Interesting, they all return > >> > >> ERROR: ino paths ioctl: No such file or directory > >> > >> So these files got deleted perhaps ? > >> > > Yeah, they must

Re: bio linked list corruption.

2016-10-21 Thread Chris Mason
On 10/21/2016 04:23 PM, Dave Jones wrote: On Fri, Oct 21, 2016 at 04:17:48PM -0400, Chris Mason wrote: > > BTRFS warning (device sda3): csum failed ino 130654 off 0 csum 2566472073 expected csum 3008371513 > > BTRFS warning (device sda3): csum failed ino 131057 off 4096 csum 3563910319

Re: bio linked list corruption.

2016-10-21 Thread Josef Bacik
On 10/21/2016 04:38 PM, Chris Mason wrote: On 10/21/2016 04:23 PM, Dave Jones wrote: On Fri, Oct 21, 2016 at 04:17:48PM -0400, Chris Mason wrote: > > BTRFS warning (device sda3): csum failed ino 130654 off 0 csum 2566472073 expected csum 3008371513 > > BTRFS warning (device sda3): csum

Re: bio linked list corruption.

2016-10-21 Thread Dave Jones
On Fri, Oct 21, 2016 at 04:17:48PM -0400, Chris Mason wrote: > > BTRFS warning (device sda3): csum failed ino 130654 off 0 csum 2566472073 > > expected csum 3008371513 > > BTRFS warning (device sda3): csum failed ino 131057 off 4096 csum > > 3563910319 expected csum 738595262 > > BTRFS

Re: bio linked list corruption.

2016-10-21 Thread Chris Mason
On 10/21/2016 04:02 PM, Dave Jones wrote: On Thu, Oct 20, 2016 at 04:23:32PM -0700, Andy Lutomirski wrote: > On Thu, Oct 20, 2016 at 4:03 PM, Dave Jones wrote: > > On Thu, Oct 20, 2016 at 04:01:12PM -0700, Andy Lutomirski wrote: > > > On Thu, Oct 20, 2016 at 3:50

Re: bio linked list corruption.

2016-10-21 Thread Dave Jones
On Thu, Oct 20, 2016 at 04:23:32PM -0700, Andy Lutomirski wrote: > On Thu, Oct 20, 2016 at 4:03 PM, Dave Jones wrote: > > On Thu, Oct 20, 2016 at 04:01:12PM -0700, Andy Lutomirski wrote: > > > On Thu, Oct 20, 2016 at 3:50 PM, Dave Jones > >

[josef-btrfs:master 3/11] mm/util.c:551:48: warning: right shift count >= width of type

2016-10-21 Thread kbuild test robot
tree: https://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git master head: d0a148ae67276be35f69f2f674913b8a1c54c4c8 commit: 51aa63bfa72fab9ec726b0b443ea92df53697502 [3/11] writeback: add counters for metadata usage config: x86_64-randconfig-x014-201642 (attached as .config)

Re: csum failed during copy/compare

2016-10-21 Thread Chris Murphy
On Fri, Oct 21, 2016 at 7:19 AM, Martin Dev wrote: > SATA trace shows device behaving correctly. > btrfs repair --ignore-errors /dev/sda2 /tmp/ will yield files that are > not verifiable by FIO, and differ from the original files on the > internal drive that they were

Re: Help repairing a partition

2016-10-21 Thread Chris Murphy
On Fri, Oct 21, 2016 at 12:36 AM, Suvayu Ali wrote: > I had upgraded to 4.7.3 to test this issue: > > https://bugzilla.redhat.com/show_bug.cgi?id=1372910 > > It hadn't helped, but I didn't have time to debug it any further. > Since the Fedora 23 repos have 4.4.1, I

Re: csum failed during copy/compare

2016-10-21 Thread Martin Dev
SATA trace shows device behaving correctly. btrfs repair --ignore-errors /dev/sda2 /tmp/ will yield files that are not verifiable by FIO, and differ from the original files on the internal drive that they were copied from at the failing offset. On Wed, Oct 19, 2016 at 3:39 PM, Martin Dev

Re: [PATCH] btrfs: change btrfs_csum_final result param type to u8

2016-10-21 Thread Domagoj Tršan
On 2016-10-12 16:43 +0200, David Sterba wrote: > On Mon, Sep 19, 2016 at 07:22:28PM +0200, David Sterba wrote: > > On Sun, Sep 18, 2016 at 12:10:34AM +0100, Domagoj Tršan wrote: > > > csum member of struct btrfs_super_block has array type of u8. It makes > > > sense > > > that function

[PATCH v2] btrfs: change btrfs_csum_final result param type to u8

2016-10-21 Thread Domagoj Tršan
csum member of struct btrfs_super_block has array type of u8. It makes sense that function btrfs_csum_final should be also declared to accept u8 *. I changed the declaration of method void btrfs_csum_final(u32 crc, char *result); to void btrfs_csum_final(u32 crc, u8 *result); ---

Re: About reflink len = 0 behavior

2016-10-21 Thread Christoph Hellwig
On Thu, Oct 20, 2016 at 08:00:05PM -0700, Darrick J. Wong wrote: > > > > For btrfs, dedupe will just return 0 and check nothing, while for xfs > > > > len == 0 means to check the whole file length. > > > > > > > > Both makes sense for me, for btrfs len = 0 behavior, it just follows > > > >

[PATCH] btrfs: imporve delayed refs iterations

2016-10-21 Thread Wang Xiaoguang
This issue was found when I tried to delete a heavily reflinked file, when deleting such files, other transaction operation will not have a chance to make progress, for example, start_transaction() will blocked in wait_current_trans(root) for long time, sometimes it even triggers soft lockups, and

Re: [PATCH v2 00/14] Btrfsck low memory mode with fs/subvol tree check

2016-10-21 Thread David Sterba
On Wed, Sep 21, 2016 at 11:15:50AM +0800, Qu Wenruo wrote: > Lu Fengqi (12): > btrfs-progs: move btrfs_extref_hash() to hash.h > btrfs-progs: check: introduce function to find dir_item > btrfs-progs: check: introduce function to check inode_ref > btrfs-progs: check: introduce function to

Re: Help repairing a partition

2016-10-21 Thread Suvayu Ali
Hi Chris, Thanks for your response :). On 21 October 2016 at 05:18, Chris Murphy wrote: > On Thu, Oct 20, 2016 at 3:20 PM, Suvayu Ali > wrote: >> Hi, >> >> (please CC me in replies, I'm not subscribed) >> >> I'm using kernel 4.7.7-100.fc23