trying to balance, filesystem keeps going read-only.

I have a file system of four 5TB drives. Well, one drive is 8TB with a 5TB partition.. the rest are 5TB drives. I created the initial btrfs file system on on drive. rsync'd data to it. added another drive. rsync'd data. added a third drive, rsync'd data. Added a four drive, trying to balance. The

Re: trying to balance, filesystem keeps going read-only.

On Sun, Nov 01, 2015 at 06:24:53AM -0500, Ken Long wrote: > I have a file system of four 5TB drives. Well, one drive is 8TB with a > 5TB partition.. the rest are 5TB drives. I created the initial btrfs > file system on on drive. rsync'd data to it. added another drive. > rsync'd data. added a

Re: Crash during mount -o degraded, kernel BUG at fs/btrfs/extent_io.c:2044

This is misleading, these error messages might make one think that the 4th drive is bad and has to be replaced, which would reduce the redundancy to the minimum because it's the second drive that's actually bad. following RFC will solve the misleading part of the problem.. [RFC PATCH]

Re: trying to balance, filesystem keeps going read-only.

I get a similar read-only status when I try to remove the drive from the array.. Too bad the utility's function can not be slowed down.. to avoid triggering this error... ? I had some success putting data *onto* the drive by croning sync every two seconds in a different terminal. Doesn't seem

Re: Crash during mount -o degraded, kernel BUG at fs/btrfs/extent_io.c:2044

On 11/01/2015 04:22 AM, Duncan wrote: So what btrfs is logging to dmesg on mount here, are the historical error counts, in this case expected as they were deliberate during your test, nearly 200K of them, not one or more new errors. To have btrfs report these at the CLI, use btrfs device

Re: trying to balance, filesystem keeps going read-only.

On Sun, 1 Nov 2015 06:24:53 -0500 Ken Long wrote: > Well, one drive is 8TB with a 5TB partition. Is this by any chance a Seagate "SMR" drive? From what I remember seeing on the list, those do not work well with Btrfs currently, with symptoms very similar to what you're

Re: trying to balance, filesystem keeps going read-only.

Yes, the one drive is that Seagate 8TB drive.. Smart tools doesn't show anything outrageous or obvious in hardware. Is there any other info I can provide to isolate, troubleshoot further? I'm not sure how to correlate the dmesg message to a specific drive, SATA cable etc.. On Sun, Nov 1,

Re: trying to balance, filesystem keeps going read-only.

On Sun, 1 Nov 2015 09:07:08 -0500 Ken Long wrote: > Yes, the one drive is that Seagate 8TB drive.. > > Smart tools doesn't show anything outrageous or obvious in hardware. > > Is there any other info I can provide to isolate, troubleshoot further? > > I'm not sure how

Re: BTRFS raid 5/6 status

I've looked into snap-raid and it seems well suited to my needs as most of the data is static. I'm planning on using it in conjunction with mhddfs so all drives are seen as a single storage pool. Is there then any benefit in using Btrfs as the underlying filesystem on each of the drives? -- To

RE: [PATCH 5/6] btrfs-progs: free comparer_set in cmd_qgroup_show

Hi, David Sterba > -Original Message- > From: David Sterba [mailto:dste...@suse.cz] > Sent: Friday, October 30, 2015 9:36 PM > To: Zhao Lei > Cc: linux-btrfs@vger.kernel.org > Subject: Re: [PATCH 5/6] btrfs-progs: free comparer_set in cmd_qgroup_show > > On Thu,

Re: [PATCH 4/4] btrfs: qgroup: account shared subtree during snapshot delete

Mark Fasheh wrote on 2015/09/22 13:15 -0700: Commit 0ed4792 ('btrfs: qgroup: Switch to new extent-oriented qgroup mechanism.') removed our qgroup accounting during btrfs_drop_snapshot(). Predictably, this results in qgroup numbers going bad shortly after a snapshot is removed. Fix this by

Re: Regression in: [PATCH 4/4] btrfs: qgroup: account shared subtree during snapshot delete

Stefan Priebe wrote on 2015/11/01 21:49 +0100: Hi, this one: http://www.spinics.net/lists/linux-btrfs/msg47377.html adds a regression to my test systems with very large disks (30tb and 50tb). btrfs balance is super slow afterwards while heavily making use of cp --reflink=always on big files

Re: Regression in: [PATCH 4/4] btrfs: qgroup: account shared subtree during snapshot delete

Stefan Priebe posted on Sun, 01 Nov 2015 21:49:44 +0100 as excerpted: > this one: http://www.spinics.net/lists/linux-btrfs/msg47377.html > > adds a regression to my test systems with very large disks (30tb and > 50tb). > > btrfs balance is super slow afterwards while heavily making use of cp >

Regression in: [PATCH 4/4] btrfs: qgroup: account shared subtree during snapshot delete

Hi, this one: http://www.spinics.net/lists/linux-btrfs/msg47377.html adds a regression to my test systems with very large disks (30tb and 50tb). btrfs balance is super slow afterwards while heavily making use of cp --reflink=always on big files (200gb - 500gb). Sorry didn't know how to

Re: Regression in: [PATCH 4/4] btrfs: qgroup: account shared subtree during snapshot delete

Am 02.11.2015 um 02:34 schrieb Qu Wenruo: Stefan Priebe wrote on 2015/11/01 21:49 +0100: Hi, this one: http://www.spinics.net/lists/linux-btrfs/msg47377.html adds a regression to my test systems with very large disks (30tb and 50tb). btrfs balance is super slow afterwards while heavily