Re: Kernel crash on mount after SMR disk trouble

10.6.2016, 23.20, Henk Slager kirjoitti: On Sat, May 14, 2016 at 10:19 AM, Jukka Larja wrote: In short: I added two 8TB Seagate Archive SMR disk to btrfs pool and tried to delete one of the old disks. After some errors I ended up with file system that can be mounted

Re: recent complete stalls of btrfs (4.6.0-rc4+) -- any advice?

? btrfs_add_link+0x384/0x3e0 [btrfs] > [3675876.816391] [] ? btrfs_link+0x143/0x220 [btrfs] > [3675876.822802] [] ? vfs_link+0x1af/0x280 > [3675876.828331] [] ? SyS_link+0x22a/0x260 > [3675876.833859] [] ? entry_SYSCALL_64_fastpath+0x1e/0xa8 > [3675876.840740] Kernel Offset: disabled >

recent complete stalls of btrfs (4.6.0-rc4+) -- any advice?

-protector: Kernel stack is corrupted in: a03d0354 [3675876.854050] * 20160610 -- again, different kaboom [443370.085059] CPU: 10 PID: 1044513 Comm: git-annex Tainted: GW IO 4.6.0-rc4+ #1 [443370.093268] Hardware name: Supermicro X10DRi/X10DRI-T, BIOS 1.0b 09/17/2014

Re: Cannot balance FS (No space left on device)

On 06/11/2016 12:10 AM, ojab // wrote: On Fri, Jun 10, 2016 at 9:56 PM, Hans van Kranenburg wrote: You can work around it by either adding two disks (like Henk said), or by temporarily converting some chunks to single. Just enough to get some free space on the

Re: Allocator behaviour during device delete

On 06/10/2016 09:58 PM, Hans van Kranenburg wrote: On 06/10/2016 09:26 PM, Henk Slager wrote: On Thu, Jun 9, 2016 at 3:54 PM, Brendan Hide wrote: On 06/09/2016 03:07 PM, Austin S. Hemmelgarn wrote: OK, I'm pretty sure I know what was going on in this case. Your

Re: Cannot balance FS (No space left on device)

On Fri, Jun 10, 2016 at 9:56 PM, Hans van Kranenburg wrote: > You can work around it by either adding two disks (like Henk said), or by > temporarily converting some chunks to single. Just enough to get some free > space on the first two disks to get a balance

Re: Cannot balance FS (No space left on device)

On 06/10/2016 11:33 PM, ojab // wrote: On Fri, Jun 10, 2016 at 9:00 PM, Henk Slager wrote: I have seldom seen an fs so full, very regular numbers :) But can you provide the output of this script: https://github.com/knorrie/btrfs-heatmap/blob/master/show_usage.py It gives

Re: Cannot balance FS (No space left on device)

On Fri, Jun 10, 2016 at 9:00 PM, Henk Slager wrote: > I have seldom seen an fs so full, very regular numbers :) > > But can you provide the output of this script: > https://github.com/knorrie/btrfs-heatmap/blob/master/show_usage.py > > It gives better info w.r.t. devices and it

Re: Cannot balance FS (No space left on device)

On Fri, Jun 10, 2016 at 8:04 PM, ojab // wrote: > [Please CC me since I'm not subscribed to the list] > Hi, > I've tried to `/usr/bin/btrfs fi defragment -r` my btrfs partition, > but it's failed w/ "No space left on device" and now I can't get any > free space on that partition

Re: [PATCH] Btrfs-progs: add check-only option for balance

Hi, Correct me if I'm wrong, On 06/09/2016 11:46 PM, Ashish Samant wrote: +/* return 0 if balance can remove a data block group, otherwise return 1 */ +static int search_data_bgs(const char *path) +{ + struct btrfs_ioctl_search_args args; + struct btrfs_ioctl_search_key *sk; +

Re: Kernel crash on mount after SMR disk trouble

On Sat, May 14, 2016 at 10:19 AM, Jukka Larja wrote: > In short: > > I added two 8TB Seagate Archive SMR disk to btrfs pool and tried to delete > one of the old disks. After some errors I ended up with file system that can > be mounted read-only, but crashes the kernel

[GIT PULL] Btrfs

Hi Linus My for-linus-4.7 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.7 Has some fixes and some new self tests for btrfs. The self tests are usually disabled in the .config file (unless you're doing btrfs dev work), and this bunch is meant to find

Re: Allocator behaviour during device delete

On 06/10/2016 09:26 PM, Henk Slager wrote: On Thu, Jun 9, 2016 at 3:54 PM, Brendan Hide wrote: On 06/09/2016 03:07 PM, Austin S. Hemmelgarn wrote: OK, I'm pretty sure I know what was going on in this case. Your assumption that device delete uses the balance code

Re: Allocator behaviour during device delete

On Thu, Jun 9, 2016 at 3:54 PM, Brendan Hide wrote: > > > On 06/09/2016 03:07 PM, Austin S. Hemmelgarn wrote: >> >> On 2016-06-09 08:34, Brendan Hide wrote: >>> >>> Hey, all >>> >>> I noticed this odd behaviour while migrating from a 1TB spindle to SSD >>> (in this case

Re: Replacing drives with larger ones in a 4 drive raid1

This is somewhat off topic but... 9.6.2016, 18.20, Duncan kirjoitti: Are those the 8 TB SMR "archive" drives? I haven't been following the issue very closely, but be aware that there were serious issues with those drives a few kernels back, and that while those issues are now fixed, the

Cannot balance FS (No space left on device)

[Please CC me since I'm not subscribed to the list] Hi, I've tried to `/usr/bin/btrfs fi defragment -r` my btrfs partition, but it's failed w/ "No space left on device" and now I can't get any free space on that partition (deleting some files or adding new device doesn't help). During defrag I've

Re: [PATCH] Btrfs-progs: add check-only option for balance

Hi all, On 2016-06-09 23:46, Ashish Samant wrote: > From: Liu Bo > > This aims to decide whether a balance can reduce the number of > data block groups and if it can, this shows the '-dvrange' block > group's objectid. > > With this, you can run > 'btrfs balance start -c

Re: fsck: to repair or not to repair

On Fri, Jun 10, 2016 at 7:22 PM, Adam Borowski wrote: > On Fri, Jun 10, 2016 at 01:12:42PM -0400, Austin S. Hemmelgarn wrote: >> On 2016-06-10 12:50, Adam Borowski wrote: >> >And, as of coreutils 8.25, the default is no reflink, with "never" not being >> >recognized even as a

Re: fsck: to repair or not to repair

On 2016-06-10 13:22, Adam Borowski wrote: On Fri, Jun 10, 2016 at 01:12:42PM -0400, Austin S. Hemmelgarn wrote: On 2016-06-10 12:50, Adam Borowski wrote: And, as of coreutils 8.25, the default is no reflink, with "never" not being recognized even as a way to avoid an alias. As far as I

Re: fsck: to repair or not to repair

On Fri, Jun 10, 2016 at 01:12:42PM -0400, Austin S. Hemmelgarn wrote: > On 2016-06-10 12:50, Adam Borowski wrote: > >And, as of coreutils 8.25, the default is no reflink, with "never" not being > >recognized even as a way to avoid an alias. As far as I remember, this > >applies to every past

Re: fsck: to repair or not to repair

On 2016-06-10 12:50, Adam Borowski wrote: On Fri, Jun 10, 2016 at 08:54:36AM -0700, Nikolaus Rath wrote: On Jun 10 2016, "Austin S. Hemmelgarn" wrote: JFYI, if you've using GNU cp, you can pass '--reflink=never' to avoid it making reflinks. I would have expected so,

Re: btrfs filesystem keeps allocating new chunks for no apparent reason

On Thu, Jun 9, 2016 at 5:41 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Hans van Kranenburg posted on Thu, 09 Jun 2016 01:10:46 +0200 as > excerpted: > >> The next question is what files these extents belong to. To find out, I >> need to open up the extent items I get back and follow a

Re: fsck: to repair or not to repair

On Jun 10 2016, Adam Borowski wrote: > On Fri, Jun 10, 2016 at 08:54:36AM -0700, Nikolaus Rath wrote: >> On Jun 10 2016, "Austin S. Hemmelgarn" wrote: >> > JFYI, if you've using GNU cp, you can pass '--reflink=never' to avoid >> > it making reflinks. >>

Re: fsck: to repair or not to repair

On Fri, Jun 10, 2016 at 08:54:36AM -0700, Nikolaus Rath wrote: > On Jun 10 2016, "Austin S. Hemmelgarn" wrote: > > JFYI, if you've using GNU cp, you can pass '--reflink=never' to avoid > > it making reflinks. > > I would have expected so, but at least in coreutils 8.23 the

Re: [PATCH 2/2] btrfs: prefix fsid to all trace events

On Thu, Jun 09, 2016 at 07:48:01PM -0400, je...@suse.com wrote: > From: Jeff Mahoney > > When using trace events to debug a problem, it's impossible to determine > which file system generated a particular event. This patch adds a > macro to prefix standard information to the

Re: fsck: to repair or not to repair

On Jun 10 2016, "Austin S. Hemmelgarn" wrote: > JFYI, if you've using GNU cp, you can pass '--reflink=never' to avoid > it making reflinks. I would have expected so, but at least in coreutils 8.23 the only valid options are "always" and "auto" (at least according to cp

Re: fsck: to repair or not to repair

On Jun 10 2016, "Austin S. Hemmelgarn" wrote: > JFYI, if you've using GNU cp, you can pass '--reflink=never' to avoid > it making reflinks. I would have expected so, but at least in coreutils 8.23 the only valid options are "never" and "auto" (at least according to cp

[PATCH] btrfs-progs: doc: add missing newline in btrfs-convert

Signed-off-by: Noah Massey --- Documentation/btrfs-convert.asciidoc | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/btrfs-convert.asciidoc b/Documentation/btrfs-convert.asciidoc index 28f9a39..ab3577d 100644 --- a/Documentation/btrfs-convert.asciidoc +++

Btrfs progs release 4.6

Hi, the btrfs-progs 4.6 have been released (no change since rc1). The biggest change is the btrfs-convert rewrite. The delayed release was caused by more testing as there were some late fixes to the code although the patchset has been in the development branch for a long time. Apart from that,

Re: fsck: to repair or not to repair

On 2016-06-09 23:40, Nikolaus Rath wrote: On May 11 2016, Nikolaus Rath wrote: Hello, I recently ran btrfsck on one of my file systems, and got the following messages: checking extents checking free space cache checking fs roots root 5 inode 3149867 errors 400, nbytes

Managing storage (incl. Btrfs) on Linux with openATTIC

Hi there, if you're using Btrfs on Linux for file serving purposes, i'd like to invite you to take a look at our open source storage management project "openATTIC": http://openattic.org/ We provide a web UI and RESTful API to create CIFS/NFS shares on top of Btrfs and other file systems,

Re: How to map extents to files

At 06/02/2016 10:56 PM, Nikolaus Rath wrote: On Jun 02 2016, Qu Wenruo wrote: At 06/02/2016 11:06 AM, Nikolaus Rath wrote: Hello, For one of my btrfs volumes, btrfsck reports a lot of the following warnings: [...] checking extents bad extent [138477568,