Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

On Fri, Sep 2, 2016 at 9:47 PM, Ronan Arraes Jardim Chagas wrote: > Hi Chris, > > Em Sex, 2016-09-02 às 21:41 -0600, Chris Murphy escreveu: >> I suggest removing the hardware, and the proprietary driver, and >> retest the system with the existing Tumbleweed 4.7.0 kernel; and if

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

Hi Chris, Em Sex, 2016-09-02 às 21:41 -0600, Chris Murphy escreveu: > I suggest removing the hardware, and the proprietary driver, and > retest the system with the existing Tumbleweed 4.7.0 kernel; and if > that still fails, then try the Leap 4.4 kernel. > > Proprietary kernels can do all kinds

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

On Fri, Sep 2, 2016 at 8:47 PM, Ronan Arraes Jardim Chagas wrote: > Hi guys! > > Em Sex, 2016-09-02 às 16:39 -0600, Chris Murphy escreveu: >> Worth a shot, considering the opensuse/SLE 4.4 kernel has a shittonne >> of backports. It seems unlikely to me opensuse intends to not

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

Hi guys! Em Sex, 2016-09-02 às 16:39 -0600, Chris Murphy escreveu: > Worth a shot, considering the opensuse/SLE 4.4 kernel has a shittonne > of backports. It seems unlikely to me opensuse intends to not support > your hardware (skylake?) Actually it is a peripheral we use to program embedded

Re: [PATCH] Btrfs: don't leak reloc root nodes on error

On Fri, Sep 02, 2016 at 03:25:43PM -0400, Josef Bacik wrote: > We don't track the reloc roots in any sort of normal way, so the only way the > root/commit_root nodes get free'd is if the relocation finishes successfully > and > the reloc root is deleted. Fix this by free'ing them in

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

On Fri, Sep 2, 2016 at 4:13 PM, Ronan Arraes Jardim Chagas wrote: > Hi! > > Em Sex, 2016-09-02 às 15:34 -0600, Chris Murphy escreveu: >> Except for your software build case, I have about the same workload >> you have with two machines, one SSD one HDD, using 4.7.0 for a month,

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

Hi! Em Sex, 2016-09-02 às 15:34 -0600, Chris Murphy escreveu: > Except for your software build case, I have about the same workload > you have with two machines, one SSD one HDD, using 4.7.0 for a month, > and then 4.7.2 for the last week. I haven't had any enospc on these > two systems. > > I

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

On Fri, Sep 2, 2016 at 1:56 PM, Ronan Arraes Jardim Chagas wrote: > Hi again guys! > > After I rebooted the computer, I still can't run balance on metatada: Except for your software build case, I have about the same workload you have with two machines, one SSD one HDD, using

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

Hi again guys! After I rebooted the computer, I still can't run balance on metatada: btrfs balance start -musage=1 / ERROR: error during balancing '/': No space left on device There may be more info in syslog - try dmesg | tail dmesg shows: [ 2022.530285] BTRFS info (device sda6): relocating

[PATCH 4/7] Btrfs: kill the start argument to read_extent_buffer_pages

Nobody uses this, it makes no sense to do partial reads of extent buffers. Signed-off-by: Josef Bacik --- fs/btrfs/disk-io.c | 13 ++--- fs/btrfs/extent_io.c | 26 +++--- fs/btrfs/extent_io.h | 2 +- 3 files changed, 14 insertions(+), 27

[PATCH 6/7] Btrfs: kill the btree_inode

In order to more efficiently support sub-page blocksizes we need to stop allocating pages from pagecache for our metadata. Instead switch to using the account_metadata* counters for making sure we are keeping the system aware of how much dirty metadata we have, and use the ->free_cached_objects

[PATCH 5/7] Btrfs: don't pass the inode through clean_io_failure

Instead pass around the failure tree and the io tree. Signed-off-by: Josef Bacik --- fs/btrfs/extent_io.c | 49 +++-- fs/btrfs/extent_io.h | 10 +++--- fs/btrfs/inode.c | 24 ++-- 3 files changed, 52

[PATCH 7/7] Btrfs: kill BUG_ON()'s in btrfs_mark_extent_written

No reason to bug on in here, fs corruption could easily cause these things to happen. Signed-off-by: Josef Bacik --- fs/btrfs/file.c | 41 + 1 file changed, 33 insertions(+), 8 deletions(-) diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c

[PATCH 2/7] btrfs: remove inode argument from repair_io_failure

Once we remove the btree_inode we won't have an inode to pass anymore, just pass the fs_info directly and the inum since we use that to print out the repair message. Signed-off-by: Josef Bacik --- fs/btrfs/extent_io.c | 14 +++--- fs/btrfs/extent_io.h | 6 +++---

[PATCH 3/7] Btrfs: add a flags field to btrfs_fs_info

We have a lot of random ints in btrfs_fs_info that can be put into flags. This is mostly equivalent with the exception of how we deal with quota going on or off, now instead we set a flag when we are turning it on or off and deal with that appropriately, rather than just having a pending state

[PATCH 1/7] Btrfs: replace tree->mapping with tree->private_data

For extent_io tree's we have carried the address_mapping of the inode around in the io tree in order to pull the inode back out for calling into various tree ops hooks. This works fine when everything that has an extent_io_tree has an inode. But we are going to remove the btree_inode, so we need

[PATCH 0/7] Kill the btree inode

In order to provide a better way to do subpage blocksizes we need to stop allocating pages from a per fs btree inode and instead allocate our own pages. This work depends on 3 generic patches that I've sent previously remove mapping from balance_dirty_pages*() writeback: allow for dirty metadata

Re: [PATCH v2] Btrfs: detect corruption when non-root leaf has zero item

Hi, On Fri, Sep 02, 2016 at 01:26:10AM -0400, Jeff Mahoney wrote: > On 8/23/16 6:22 PM, Liu Bo wrote: > > Right now we treat leaf which has zero item as a valid one > > because we could have an empty tree, that is, a root that is > > also a leaf without any item, however, in the same case but > >

[PATCH] Btrfs: fix BUG_ON in btrfs_mark_buffer_dirty

This can only happen with CONFIG_BTRFS_FS_CHECK_INTEGRITY=y. Commit 1ba98d0 ("Btrfs: detect corruption when non-root leaf has zero item") assumes that a leaf is its root when leaf->bytenr == btrfs_root_bytenr(root), however, we should not use btrfs_root_bytenr(root) since it's mainly got updated

[PATCH] Btrfs: don't leak reloc root nodes on error

We don't track the reloc roots in any sort of normal way, so the only way the root/commit_root nodes get free'd is if the relocation finishes successfully and the reloc root is deleted. Fix this by free'ing them in free_reloc_roots. Thanks, Signed-off-by: Josef Bacik ---

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

Hi guys! Jeff was right. I had the problem again today and quotas are disabled now. I couldn't get any useful message in log this time. Look at the metadata: btrfs fi usage / Overall: Device size:   1.26TiB Device allocated:   43.07GiB Device unallocated:

Re: kernel BUG at fs/btrfs/ctree.c:5213

On Fri, Sep 02, 2016 at 04:58:43PM +0200, ste...@srv1.eu wrote: > Hi, > > since a few weeks ago, my BTRFS (the root file system) sporadically crashes > leaving a "kernel BUG" message in dmesg. I also noticed some files behaving > like this: > > $ ls -lai > ls: cannot access 'nlpsolver.jar':

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

On 9/2/16 11:20 AM, Ronan Arraes Jardim Chagas wrote: > Hi Jeff, > > Em Sex, 2016-09-02 às 10:48 -0400, Jeff Mahoney escreveu: >> Sorry, I miscommunicated there. The WARN_ON is annoying. It's the >> underlying issue that's causing you to lose work that is the one that >> concerns me. >> > >

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

Hi Jeff, Em Sex, 2016-09-02 às 10:48 -0400, Jeff Mahoney escreveu: > Sorry, I miscommunicated there.  The WARN_ON is annoying.  It's the > underlying issue that's causing you to lose work that is the one that > concerns me. >  Oh, OK, I see, sorry about that :) Thus, if disabling quotas does

[PATCH] btrfs-progs: dump-super: changes in options to specify superblocks

Some tools (check, select-super, dump-super) can use the alternate superblocks, but the options are not consistent. To make it less confusing, change the meaning of option -s in 'dump-super' to specify the superblock copy, instead of taking the offset. Though this is a change in UI, the old usage

kernel BUG at fs/btrfs/ctree.c:5213

Hi, since a few weeks ago, my BTRFS (the root file system) sporadically crashes leaving a "kernel BUG" message in dmesg. I also noticed some files behaving like this: $ ls -lai ls: cannot access 'nlpsolver.jar': Stale file handle ls: cannot access 'EvolutionarySolver.jar': Stale file handle

Re: your mail

On 2016-09-01 12:44, Kyle Gates wrote: -Original Message- From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs- ow...@vger.kernel.org] On Behalf Of Austin S. Hemmelgarn Sent: Thursday, September 01, 2016 6:18 AM To: linux-btrfs@vger.kernel.org Subject: Re: your mail On 2016-09-01

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

On 9/2/16 10:43 AM, Ronan Arraes Jardim Chagas wrote: > Hi Jeff, > > Em Sex, 2016-09-02 às 10:26 -0400, Jeff Mahoney escreveu: >> I explained what I think Ronan's issue is in another part of the >> thread >> just now. I don't think that's a severe issue at >> all. Annoying? Sure, >> but I'm

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

Hi Jeff, Em Sex, 2016-09-02 às 10:26 -0400, Jeff Mahoney escreveu: > I explained what I think Ronan's issue is in another part of the > thread > just now.  I don't think that's a severe issue at > all.  Annoying?  Sure, > but I'm more concerned with the underlying ENOSPC issue.  Without > more >

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

On 9/1/16 8:12 PM, Chris Murphy wrote: > On Thu, Sep 1, 2016 at 12:47 PM, Austin S. Hemmelgarn > wrote: > > >> 2. Snapper's default snapshot creation configuration is absolutely >> pathological in nature, generating insane amounts of background resource >> usage and taking

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

On 8/31/16 4:49 PM, Ronan Arraes Jardim Chagas wrote: > Hi guys! > > And the problem happened again. This time, I was only using Mozilla > Firefox. I could get the very first message after the error. I hope it > brings more information: Ok, so I think this is a race that can happen when one

Re: [PATCH] btrfs: let btrfs_delete_unused_bgs() to clean relocated bgs

On 09/02/2016 03:46 AM, Naohiro Aota wrote: Currently, btrfs_relocate_chunk() is removing relocated BG by itself. But the work can be done by btrfs_delete_unused_bgs() (and it's better since it trim the BG). Let's dedupe the code. While btrfs_delete_unused_bgs() is already hitting the relocated

Re: [PATCH] btrfs: introduce tickets_id to determine whether asynchronous metadata reclaim work makes progress

On 09/01/2016 10:58 PM, Wang Xiaoguang wrote: In btrfs_async_reclaim_metadata_space(), we use ticket's address to determine whether asynchronous metadata reclaim work is making progress. ticket = list_first_entry(_info->tickets, struct reserve_ticket,

Re: [OT] Re: Balancing subvolume on a specific device

Kai Krakow posted on Thu, 01 Sep 2016 21:45:19 +0200 as excerpted: > Am Sat, 20 Aug 2016 06:30:11 + (UTC) > schrieb Duncan <1i5t5.dun...@cox.net>: > >> There's at least three other options to try to get what you mention, >> however. FWIW, I'm a gentooer and thus build everything from

[PATCH] btrfs: let btrfs_delete_unused_bgs() to clean relocated bgs

Currently, btrfs_relocate_chunk() is removing relocated BG by itself. But the work can be done by btrfs_delete_unused_bgs() (and it's better since it trim the BG). Let's dedupe the code. While btrfs_delete_unused_bgs() is already hitting the relocated BG, it skip the BG since the BG has "ro" flag

Re: [PATCH 1/2] btrfs-progs: mkfs: Warn user for minimal RAID5/6 devices setup

+1 for the note/warning! > Am 02.09.2016 um 03:59 schrieb Steven Haigh : > > --7NtBNafxaf8ODulNFrivgmW7Mjs09oWwR > Content-Type: text/plain; charset=windows-1252 > Content-Transfer-Encoding: quoted-printable > > Is it worthwhile adding a note that RAID5 / RAID6 may very well