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
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
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
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
$ 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
...
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
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
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
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
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
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
> >
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)
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
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
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
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
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);
---
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
> > > >
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
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
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
21 matches
Mail list logo