Hi,
I've been using a btrfs volume in a NFS server for some time, based in
iscsi storage with 4k sectors. Due to problems with NFS I've decided to
drop iscsi and make the iscsi target server (standard x86 box with raid
drive) a secondary NFS server.
This requires mounting the btrfs volume
Chris Samuel posted on Mon, 04 Aug 2014 20:24:46 +1000 as excerpted:
On Mon, 4 Aug 2014 11:56:46 AM Clemens Eisserer wrote:
Which doesn't protect the *average* user from running into issues like
this.
No, but they need to be aware of it.
Actually, an ordinary user/admin /should/ have no
Austin S Hemmelgarn posted on Mon, 04 Aug 2014 13:09:23 -0400 as
excerpted:
Think of each chunk like a box, and each block as a block, and that you
have two different types of block (data and metadata) and two different
types of box (also data and metadata). The data boxes are four times the
Original Message
Subject: Re: ENOSPC with mkdir and rename
From: Peter Waller pe...@scraperwiki.com
To: Qu Wenruo quwen...@cn.fujitsu.com
Date: 2014年08月04日 16:14
Thanks for responses.
All of this is *very* surprising. I'm not new to BTRFS, I've been
using it on my own
On 04 August 2014 at 20:31 Zach Brown z...@zabbo.net wrote:
On Sat, Aug 02, 2014 at 02:24:49PM +0200, Fabian Frederick wrote:
On Thu, 17 Jul 2014 12:01:52 -0700
Zach Brown z...@zabbo.net wrote:
@@ -515,7 +515,8 @@ static int write_buf(struct file *filp, const
void *buf,
I already posted this in the thread ENOSPC with mkdir and rename,
but now I have a device with 100GB unallocated on the btrfs fi sh
output, and when I run a rebalance of the form:
btrfs filesystem balance start -dusage=50 -musage=10 $mount
I get more than 75 of such stack traces contaminating
On Tue, Aug 05, 2014 at 10:34:13AM +0100, Peter Waller wrote:
I already posted this in the thread ENOSPC with mkdir and rename,
but now I have a device with 100GB unallocated on the btrfs fi sh
output, and when I run a rebalance of the form:
btrfs filesystem balance start -dusage=50
On 5 August 2014 10:46, Hugo Mills h...@carfax.org.uk wrote:
It's a warning, not an oops, so it's less immediately dangerous.
The other key thing is block rsv returned -28, which says it's an
ENOSPC. My guess would be that you've got ENOSPC debugging enabled in
the kernel, and that the
My current interpretation of this problem is that it is some
pathological condition caused by not rebalancing and being nearly out
of space for allocating more metadata and hence it is rarely being
seen by anyone else (because most users are regularly doing
rebalances).
See this thread for
On 2014-08-05 04:20, Duncan wrote:
Austin S Hemmelgarn posted on Mon, 04 Aug 2014 13:09:23 -0400 as
excerpted:
Think of each chunk like a box, and each block as a block, and that you
have two different types of block (data and metadata) and two different
types of box (also data and
Hi Russel,
The Debian installer has BTRFS in a list of filesystems to choose with no
special notice about it. I'm thinking of filing a Debian bug requesting that
they put a warning against it.
As long as it is not selected as the default filesystem, I think it is fine.
Other distributions
On 5 August 2014 13:58, Clemens Eisserer linuxhi...@gmail.com wrote:
As long as it is not selected as the default filesystem, I think it is fine.
Other distributions have been offering btrfs for some time now, too.
How do you warn non-BTRFS-developers in this case that they need to
run a
root@a i ~ # iostat
Linux 3.14.15-1-lts (eanna) 08/04/2014 _x86_64_ (24 CPU)
(...)
How do I boil those numbers down to something meaningful, so I can get
an idea of the throughput in situ?
Simple iostat won't give you meaningful live performance stats.
You can combine it i.e. like below:
Hello Zach,
Here's an untested patch which
Try testing it. It's easy with virtualization and xfstests.
You'll find that sending to a file fails because each individual file
write call that makes up a send starts at offset 0 -- at the start of
the file.
Getting this
On Tue, Aug 5, 2014 at 7:14 AM, Tomasz Chmielewski man...@wpkg.org wrote:
Simple iostat won't give you meaningful live performance stats.
You can combine it i.e. like below:
iostat -x 1
iostat -mx 1
iostat -m 1
Thanks for the pointer about viewing the extended stats, and showing
them in MB
On 2014-08-06 00:06, G. Richard Bellamy wrote:
On Tue, Aug 5, 2014 at 7:14 AM, Tomasz Chmielewski man...@wpkg.org
wrote:
Simple iostat won't give you meaningful live performance stats.
You can combine it i.e. like below:
iostat -x 1
iostat -mx 1
iostat -m 1
Thanks for the pointer about
Russell Coker posted on Tue, 05 Aug 2014 22:20:33 +1000 as excerpted:
The Debian installer has BTRFS in a list of filesystems to choose with
no special notice about it. I'm thinking of filing a Debian bug
requesting that they put a warning against it.
What do people here think?
You
On Tue, Aug 5, 2014 at 5:20 AM, Russell Coker russ...@coker.com.au wrote:
Based on what I've read on this list it seems that BTRFS is less stable in
3.15 than in 3.14. Even 3.14 isn't something I'd recommend to random people
who want something to just work.
The Debian installer has BTRFS
Current BTRFS_IOC_DEV_REPLACE ioctl is synchronous, and during the ioctl
program is fallen into kernel and unable to handle signal, the original
signal function will never be executed until the dev replace is done.
This is very annoying for someone who wants to stop dev replace by
Ctrl-c (we have
On Tue, Aug 5, 2014 at 8:38 PM, ronnie sahlberg
ronniesahlb...@gmail.com wrote:
On Tue, Aug 5, 2014 at 5:20 AM, Russell Coker russ...@coker.com.au wrote:
Based on what I've read on this list it seems that BTRFS is less stable in
3.15 than in 3.14. Even 3.14 isn't something I'd recommend to
20 matches
Mail list logo
