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 di
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/ h
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
To: Qu Wenruo
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 machines for multiple years. I didn't realise there
> On 04 August 2014 at 20:31 Zach Brown 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 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 contamina
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=5
On 5 August 2014 10:46, Hugo Mills 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 backtraces, while
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 details
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
On Tue, 5 Aug 2014 16:51:44 Qu Wenruo wrote:
> In fact such "defeat"(or whatever) is not really btrfs only problem.
> In ext*, there is still similiar behavior: ext* has a up limit on the
> number of inode after mkfs.
> (When you mkfs.ext*, you are prompt the up limit of inodes)
> However other me
On Tue, 5 Aug 2014 08:06:12 Duncan wrote:
> Which is why I'm not particularly happy with seeing all the "btrfs is
> still not stable, use at your own risk" warnings disappearing. With them
> there, people who chose to run btrfs /could/ be expected to have done
> their research and have btrfs sp
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 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 regular rebalance or they
On Tue, 5 Aug 2014 10:20:33 PM Russell Coker wrote:
> 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.
I think it's a good plan. People should be aware of t
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:
ios
> > > 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.
On Tue, Aug 5, 2014 at 7:14 AM, Tomasz Chmielewski 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 rather t
On 2014-08-06 00:06, G. Richard Bellamy wrote:
On Tue, Aug 5, 2014 at 7:14 AM, Tomasz Chmielewski
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
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 al
On Tue, Aug 5, 2014 at 5:20 AM, Russell Coker 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 in a list of fil
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 t
On Tue, Aug 5, 2014 at 8:38 PM, ronnie sahlberg
wrote:
> On Tue, Aug 5, 2014 at 5:20 AM, Russell Coker 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
23 matches
Mail list logo
