e Data part hit 3.36TB, those usages of sdd1,
sde1 and sdh1 have been fluctuating up and down between around 850GB up to
around those values shown right now.
Is there any way I can find out what's going on?
--
Fredrik Tolf
--
To unsubscribe from this list: send the line "unsubscrib
On Wed, 27 Feb 2013, Liu Bo wrote:
On Sat, Feb 23, 2013 at 01:46:03AM +0100, Fredrik Tolf wrote:
If I were transferring the data to a new filesystem on mdraid, the
procedure I would use for that last portion of the data would be to
remove one disk only from either of the old mdraid mirror
n algorithm without having to
rebalance the existing data, which seems a bit unnecessary in this case.
Thanks for any help you can offer!
--
Fredrik Tolf
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More m
On Mon, 18 Feb 2013, Stefan Behrens wrote:
On Fri, 15 Feb 2013 22:56:19 +0100 (CET), Fredrik Tolf wrote:
The oops cut can be found here:
<http://www.dolda2000.com/~fredrik/tmp/btrfs-oops>
This scrub issue is fixed since Linux 3.8-rc1 with commit
4ded4f6 Btrfs: fix BUG() in scrub when
mp/btrfs-oops>
So with that, I'm certainly going to reboot the machine. :)
--
Fredrik Tolf
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 14 Feb 2013, Chris Murphy wrote:
Also, is a virtual machine being used in any of this, either as host or guest?
Nope.
--
Fredrik Tolf
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordo
On Thu, 14 Feb 2013, Chris Murphy wrote:
On Feb 14, 2013, at 8:50 PM, Fredrik Tolf wrote:
So it's either from btrfs, or from the buffer cache, and seeing as how it
appears with other btrfs messages, I'd be willing to bet on the former. :)
Unclear. Google searches reveal this
ntk_ratelimited_in_rcu(KERN_WARNING "lost page write due to "
"I/O error on %s\n",
rcu_str_deref(device->name));
So it's either from btrfs, or from the buffer cache, and seeing as how it
appears with other btrfs messa
On Thu, 14 Feb 2013, Martin Steigerwald wrote:
Am Mittwoch, 13. Februar 2013 schrieb Fredrik Tolf:
You started the balance after above btrfs fi show command?
I did.
Then its obvious to me:
For some reason BTRFS is still trying to write to /dev/sdd, which isn´t
there anymore. That perfectly
769.574831] ata6.00: status: { DRDY ERR }
Feb 12 16:36:52 nerv kernel: [36769.578867] ata6.00: error: { ICRC ABRT }
Just to be overly redundant: I'm not getting those anymore, and I only
ever got them before the drive was redetected as sdi.
--
Fredrik Tolf
--
To unsubscribe from this list:
On Wed, 13 Feb 2013, Chris Murphy wrote:
On Feb 12, 2013, at 11:18 PM, Fredrik Tolf wrote:
That's not typical for actual media problems, in my experience. :)
Quite typical, because these drives don't support SCTERC which almost
certainly means their error timeouts are well above t
On Tue, 12 Feb 2013, Chris Murphy wrote:
On Feb 12, 2013, at 4:01 PM, Fredrik Tolf wrote:
mkfs.btrfs -d raid -m raid1 /dev/sd{d,e}1
Is that a typo? -d raid isn't valid.
Ah yes, sorry. That was a typo.
What do you get for:
btrfs fi df /mnt
$ sudo ./btrfs fi df /mnt
Data, RAID1:
name since that's how I mounted
it, or is it still trying to access the old removed instance of that disk
and is that, then, why it's giving all these errors?
Thanks for reading!
--
Fredrik Tolf
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
13 matches
Mail list logo
