Re: problems with btrfs send / restore

Am 15.10.2012 22:14, schrieb Alex Lyakas: Stefan, the second issue you're seeing was discussed here: http://www.spinics.net/lists/linux-btrfs/msg19672.html You can apply the patch I sent there meanwhile, but as Miao pointed out, I will need to make a better patch (hope will do it soon, together

Production use with vanilla 3.6.6

Hello list, is btrfs ready for production use in 3.6.6? Or should i backport fixes from 3.7-rc? Is it planned to have a stable kernel which will get all btrfs fixes backported? Greets Stefan -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to

problem with ceph and btrfs patch: set journal_info in async trans commit worker

Hello list, i wanted to try out ceph with latest vanilla kernel 3.7-rc5. I was seeing a massive performance degration. I see around 22x btrfs-endio-write processes every 10-20 seconds and they run a long time while consuming a massive amount of CPU. So my performance of 23.000 iops drops to

Re: problem with ceph and btrfs patch: set journal_info in async trans commit worker

Hi Miao, Am 15.11.2012 06:18, schrieb Miao Xie: Hi, Stefan On wed, 14 Nov 2012 14:42:07 +0100, Stefan Priebe - Profihost AG wrote: Hello list, i wanted to try out ceph with latest vanilla kernel 3.7-rc5. I was seeing a massive performance degration. I see around 22x btrfs-endio-write

Re: btrfs deadlock in 3.5-rc3

Am 25.06.2012 15:08, schrieb Josef Bacik: This isn't showing the guy who's actually trying to commit the transaction. Next time this happens can you do a sysrq+w and capture the output and post it here so we can see what everybody is doing? Thanks, Josef No problem. Kernel trace:

Re: btrfs deadlock in 3.5-rc3

Thats weird, sysrq+w should have a bunch of stacktraces but it's empty, so unless theres a bug theres nothing blocked. Is the box actually hung or is it just taking forever? Maybe try sysrq+w again to see if the one you pasted was just a fluke? Thanks, This one looks better:

Re: btrfs deadlock in 3.5-rc3

Yes i will do so. Right now i was trying to compare discard with non discard with this simple command: for i in `seq 0 1 1000`; do dd if=/dev/zero of=t_$i bs=4M count=1; rm t_$i; done; But i hit a new bug: [39577.660228] BUG: unable to handle kernel paging request at fe50

No space left on device (28)

Hi, while copying a 15GB file to my btrfs volume i'm getting No space left on device. Some information: # btrfs filesystem df /mnt/ Data: total=18.14TB, used=15.05TB System, DUP: total=8.00MB, used=1.94MB System: total=4.00MB, used=0.00 Metadata, DUP: total=23.98GB, used=17.97GB Metadata:

Re: No space left on device (28)

Hi Chris, Am 21.03.2013 um 19:00 schrieb Chris Mason chris.ma...@fusionio.com: Quoting Stefan Priebe - Profihost AG (2013-03-21 04:03:04) Hi, while copying a 15GB file to my btrfs volume i'm getting No space left on device. Some information: # btrfs filesystem df /mnt/ Data: total

Re: No space left on device (28)

Am 21.03.2013 20:02, schrieb Chris Mason: Quoting Stefan Priebe - Profihost AG (2013-03-21 14:35:59) Hi Chris, Am 21.03.2013 um 19:00 schrieb Chris Mason chris.ma...@fusionio.com: Quoting Stefan Priebe - Profihost AG (2013-03-21 04:03:04) Hi, while copying a 15GB file to my btrfs

Re: No space left on device (28)

, schrieb Chris Mason: Quoting Stefan Priebe - Profihost AG (2013-03-21 14:35:59) Hi Chris, Am 21.03.2013 um 19:00 schrieb Chris Mason chris.ma...@fusionio.com: Quoting Stefan Priebe - Profihost AG (2013-03-21 04:03:04) Hi, while copying a 15GB file to my btrfs volume i'm getting No space

Re: No space left on device (28)

Already tried with value 5 did not help ;-( and it also happens with plain cp copying a 15gb file and aborts at about 80% Am 22.03.2013 um 07:24 schrieb cwillu cwi...@cwillu.com: On Fri, Mar 22, 2013 at 12:13 AM, Roman Mamedov r...@romanrm.ru wrote: On Thu, 21 Mar 2013 20:42:28 +0100 Stefan

Re: No space left on device (28)

Hi, Am 22.03.2013 07:41, schrieb cwillu: On Fri, Mar 22, 2013 at 12:39 AM, Stefan Priebe - Profihost AG s.pri...@profihost.ag wrote: Already tried with value 5 did not help ;-( and it also happens with plain cp copying a 15gb file and aborts at about 80% You tried -musage=5? Your original

Re: No space left on device (28)

Hi Chris, Which kernel are you running? -chris vanilla 3.8.3. Ok, with the 3.9 merge window Josef changed how we do the reservations. Are you able to try a slightly more experimental kernel? any ideas what i can check? 3.9-rc3 gives me same results. Greets, Stefan -- To unsubscribe from

Re: No space left on device (28)

Hi Josef, Am 22.03.2013 14:53, schrieb Josef Bacik: On Fri, Mar 22, 2013 at 06:11:56AM -0600, Stefan Priebe - Profihost AG wrote: Hi Chris, Which kernel are you running? -chris vanilla 3.8.3. Ok, with the 3.9 merge window Josef changed how we do the reservations. Are you able to try

Re: No space left on device (28)

Hi Josef, Am 26.03.2013 13:53, schrieb Josef Bacik: On Tue, Mar 26, 2013 at 01:45:42AM -0600, Stefan Priebe wrote: Hi, output here: [ 590.546162] returning enospc, space_info 3, size 0 reserved 0, flush 2, flush_state 7 dumping space info [ 590.548280] space_info 4 has 6439292928 free,

Re: No space left on device (28)

Hi Josef, Am 26.03.2013 14:30, schrieb Josef Bacik: On Tue, Mar 26, 2013 at 06:55:23AM -0600, Stefan Priebe - Profihost AG wrote: Hi Josef, Am 26.03.2013 13:53, schrieb Josef Bacik: On Tue, Mar 26, 2013 at 01:45:42AM -0600, Stefan Priebe wrote: Hi, output here: [ 590.546162] returning

Re: No space left on device (28)

Hi, Am 26.03.2013 15:44, schrieb Josef Bacik: Am 26.03.2013 13:53, schrieb Josef Bacik: no - it's just mounted with mount -o noatime :~# cat /proc/mounts | grep btrfs /dev/mapper/raid54tb1 /mnt btrfs rw,noatime,space_cache 0 0 Ok I think I see what's going on. Can you try this patch and

4.2-rc6: kernel BUG at fs/btrfs/inode.c:3230

Seen today: [150110.712196] [ cut here ] [150110.776995] kernel BUG at fs/btrfs/inode.c:3230! [150110.841067] invalid opcode: [#1] SMP [150110.904472] Modules linked in: dm_mod netconsole ipt_REJECT nf_reject_ipv4 xt_multiport iptable_filter ip_tables x_tables

4.2-rc6: cp reflink call trace

I'm getting the following trace on a daily basis when stacking a lot of cp --reflink commands. Somethinkg like: File a 80GB cp --reflink=always a b modify b cp --reflink=always b c modify c cp --reflink=always c d modify d ... [57623.099897] INFO: task cp:1319 blocked for more than 120

Re: slowdown after one week

Am 13.07.2015 um 13:20 schrieb Austin S Hemmelgarn: On 2015-07-11 02:46, Stefan Priebe wrote: Hi, while using a 40TB btrfs partition for VM backups. I see a massive slowdown after around one week. The backup task takes usally 2-3 hours. After one week it takes 20 hours. If i umount and

out of space on big devices 30tb

Hello list, I get constantly no space messages friends m btrfs on big volumes. Btrfs balance always fixes it for 2-3 days. Now I'm in the process to recreate the fs. Are there any options I could pass to mods.btrfs which help to prevent this? Special use case heavy usage of cp reflink and

Re: Regression in btrfs: properly set the termination value of ctx->pos in readdir

Hi, the patch btrfs: properly set the termination value of ctx->pos in readdir introduces a regression to me. A lot of stuff runs in "endless" or long running loops. An example strace looks like this: msgsnd(0, {1, "\3\0\0\0\247\r\0\0g8\0\0\0\0\0\0\0\0\0\0\345<\1\0\0\0\0\0\35\0\0\0"...}, 56, 0)

Re: btrfs regression since 4.X kernel NULL pointer dereference

Am 25.08.2015 um 11:00 schrieb Christoph Hellwig: I think this is btrfs using a struct block_device that doesn't have a valid queue pointer in it's gendisk for -s_bdev. And there are some fishy looking -s_bdev assignments in the code which I suspect are related to it:

Re: btrfs no space BTRFS: block rsv returned -28

is disabled. Stefan Am 27.08.2015 um 08:23 schrieb Stefan Priebe - Profihost AG: Hi, today i had again the no space situation while having the device mounted with: enospc_debug # btrfs filesystem df /vmbackup/ Data, single: total=18.54TiB, used=17.94TiB System, DUP: total=32.00MiB, used

btrfs no space BTRFS: block rsv returned -28

Hi, today i had again the no space situation while having the device mounted with: enospc_debug # btrfs filesystem df /vmbackup/ Data, single: total=18.54TiB, used=17.94TiB System, DUP: total=32.00MiB, used=2.83MiB Metadata, DUP: total=126.00GiB, used=99.45GiB GlobalReserve, single:

Re: btrfs regression since 4.X kernel NULL pointer dereference

> Am 25.08.2015 um 15:51 schrieb Chris Mason : > >> On Tue, Aug 25, 2015 at 11:00:30AM +0200, Christoph Hellwig wrote: >> I think this is btrfs using a struct block_device that doesn't have >> a valid queue pointer in it's gendisk for ->s_bdev. And there are >> some fishy looking

Aborting unused transaction

Hi, [447062.309251] Modules linked in: dm_mod netconsole ipt_REJECT nf_reject_ipv4 xt_multiport iptable_filter ip_tables x_tables cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_conservative bonding ext2 usbhid coretemp loop ehci_pci sb_edac ehci_hcd edac_core i2c_i801 i2c_core usbcore

Re: btrfs goes readonly + No space left on 4.3

Am 03.05.2016 um 00:05 schrieb Omar Sandoval: > On Fri, Apr 29, 2016 at 10:48:15PM +0200, Stefan Priebe wrote: >> just want to drop a note that all those ENOSPC msg are gone with v4.5 and >> space_cache=v2. Any plans to make space_cache=v2 default? >> >> Greets, >> Stefan > > Yup, we want to

Re: ENOSPC / no space on very large devices

here we go... Am 20.07.2016 um 08:31 schrieb Wang Xiaoguang: > hello, > > On 07/20/2016 01:31 PM, Stefan Priebe - Profihost AG wrote: >> Hi list, >> >> while i didn't had the problem for some month i'm now getting ENOSPC on >> a regular basis on one host. >&

Re: ENOSPC / no space on very large devices

Am 20.07.2016 um 09:35 schrieb Holger Hoffstätte: > On 07/20/16 07:31, Stefan Priebe - Profihost AG wrote: >> Hi list, >> >> while i didn't had the problem for some month i'm now getting ENOSPC on >> a regular basis on one host. > > Well, it's getting b

Re: memory overflow or undeflow in free space tree / space_info?

Am 29.07.2016 um 21:14 schrieb Omar Sandoval: > On Fri, Jul 29, 2016 at 12:11:53PM -0700, Omar Sandoval wrote: >> On Fri, Jul 29, 2016 at 08:40:26PM +0200, Stefan Priebe - Profihost AG wrote: >>> Dear list, >>> >>> i'm seeing btrfs no space messages f

Re: memory overflow or undeflow in free space tree / space_info?

Am 29.07.2016 um 21:11 schrieb Omar Sandoval: > On Fri, Jul 29, 2016 at 08:40:26PM +0200, Stefan Priebe - Profihost AG wrote: >> Dear list, >> >> i'm seeing btrfs no space messages frequently on big filesystems (> 30TB). >> >> In all cases i'm getting a trac

Re: memory overflow or undeflow in free space tree / space_info?

=5 SYSTEM (flags 0x2): balancing, usage=5 dmesg: [203784.411189] BTRFS info (device dm-0): 114 enospc errors during balance uname -r 4.7.0-rc6-29043-g8b8b08c Greets, Stefan Am 08.08.2016 um 08:17 schrieb Stefan Priebe - Profihost AG: > Am 04.08.2016 um 13:40 schrieb Stefan Priebe - Profih

Re: memory overflow or undeflow in free space tree / space_info?

Am 29.07.2016 um 23:03 schrieb Josef Bacik: > On 07/29/2016 03:14 PM, Omar Sandoval wrote: >> On Fri, Jul 29, 2016 at 12:11:53PM -0700, Omar Sandoval wrote: >>> On Fri, Jul 29, 2016 at 08:40:26PM +0200, Stefan Priebe - Profihost >>> AG wrote: >>>> Dear li

Re: memory overflow or undeflow in free space tree / space_info?

Hi Josef, anything i could do or test? Results with a vanilla next branch are the same. Stefan Am 11.08.2016 um 08:09 schrieb Stefan Priebe - Profihost AG: > Hello, > > the backtrace and info on umount looks the same: > > [241910.341124] [ cut here ] &

Re: memory overflow or undeflow in free space tree / space_info?

]--- [241915.982893] BTRFS: space_info 4 has 114577997824 free, is not full [241916.045103] BTRFS: space_info total=307627032576, used=193048903680, pinned=0, reserved=0, may_use=688537059328, readonly=131072 Greets, Stefan Am 10.08.2016 um 23:31 schrieb Stefan Priebe - Profihost AG: > Hi Jo

ENOSPC / no space on very large devices

Hi list, while i didn't had the problem for some month i'm now getting ENOSPC on a regular basis on one host. It would be great if someone can help me debugging this. Some basic informations: # touch /vmbackup/abc touch: cannot touch `/vmbackup/abc': No space left on device # df -h /vmbackup/

Re: memory overflow or undeflow in free space tree / space_info?

Am 04.08.2016 um 13:40 schrieb Stefan Priebe - Profihost AG: > Am 29.07.2016 um 23:03 schrieb Josef Bacik: >> On 07/29/2016 03:14 PM, Omar Sandoval wrote: >>> On Fri, Jul 29, 2016 at 12:11:53PM -0700, Omar Sandoval wrote: >>>> On Fri, Jul 29, 2016 at 08:40:26PM +0

memory overflow or undeflow in free space tree / space_info?

Dear list, i'm seeing btrfs no space messages frequently on big filesystems (> 30TB). In all cases i'm getting a trace like this one a space_info warning. (since commit [1]). Could someone please be so kind and help me debugging / fixing this bug? I'm using space_cache=v2 on all those systems.

high cpu usage due to btrfs_find_space_for_alloc and rb_next

Hi, is there any chance to optimize btrfs_find_space_for_alloc / rb_next on big devices? I've plenty of free space but most of the time there's only low I/O but high cpu usage. perf top shows: 60,41% [kernel] [k] rb_next 9,74% [kernel] [k]

Re: [PATCH 0/3] introduce type based delalloc metadata reserve to fix some false enospc issues

Dear Qu, any news on your branch? I still don't see it merged anywhere. Greets, Stefan Am 04.01.2017 um 17:13 schrieb Stefan Priebe - Profihost AG: > Hi Qu, > > Am 01.01.2017 um 10:32 schrieb Qu Wenruo: >> Hi Stefan, >> >> I'm trying to push it to for-next (will be

Re: [PATCH 0/3] introduce type based delalloc metadata reserve to fix some false enospc issues

Hi, can please anybody comment on that one? Josef? Chris? I still need those patches to be able to let btrfs run for more than 24hours without ENOSPC issues. Greets, Stefan Am 27.02.2017 um 08:22 schrieb Qu Wenruo: > > > At 02/25/2017 04:23 PM, Stefan Priebe - Profihost AG wrote: &

Re: btrfs and systemd

).d/ # cat > /etc/systemd/system/$(systemd-escape --suffix=mount -p /foo/bar/baz).d/timeout.conf < 2016-08-29 9:28 GMT+03:00 Stefan Priebe - Profihost AG > <s.pri...@profihost.ag>: >> Hi Qu, >> >> Am 29.08.2016 um 03:48 schrieb Qu Wenruo: >>> >>> &g

Re: [PATCH v3] btrfs: should block unused block groups deletion work when allocating data space

Thanks, this one works fine. No deadlocks. Stefan Am 09.09.2016 um 10:17 schrieb Wang Xiaoguang: > cleaner_kthread() may run at any time, in which it'll call > btrfs_delete_unused_bgs() > to delete unused block groups. Because this work is asynchronous, it may also > result > in false ENOSPC

btrfs_endio_write_helper hard lock blocked qorkqueues with kernel 4.8-rc5

Hi, today i've seen this one with 4.8-rc5 and the system was going to be unresponsible. BUG: workqueue lockup - pool cpus=14 node=1 flags=0x0 nice=0 stuck for 33s! BUG: workqueue lockup - pool cpus=14 node=1 flags=0x0 nice=-20 stuck for 33s! Showing busy workqueues and worker pools: workqueue

ENOSPACE linux 4.8-rc6 BTRFS: space_info 4 has 18446743524878843904 free, is not full

Hi, this is vanilla linux 4.8-rc6 and i still have ENOSPC issues with btrfs - caused by wrong space_tree entries. [ 9736.921995] [ cut here ] [ 9736.923342] WARNING: CPU: 1 PID: 23942 at fs/btrfs/extent-tree.c:5734 btrfs_free_block_groups+0x35e/0x440 [btrfs] [

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Thanks Wang, i applied them both on top of vanilla v4.8 - i hope this is OK. Will report back what happens. Greets, Stefan Am 06.10.2016 um 05:04 schrieb Wang Xiaoguang: > Hi, > > On 09/29/2016 03:27 PM, Stefan Priebe - Profihost AG wrote: >> Am 29.09.2016 um 09:13 schrieb

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Thanks Wang, i applied them both on top of vanilla v4.8 - i hope this is OK. Will report back what happens. Greets, Stefan Am 06.10.2016 um 05:04 schrieb Wang Xiaoguang: > Hi, > > On 09/29/2016 03:27 PM, Stefan Priebe - Profihost AG wrote: >> Am 29.09.2016 um 09:13 schrieb

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

main difference between the system where oom happens is: - Single Xeon => no OOM - Dual Xeon / NUMA => OOM both 64GB mem. Am 07.10.2016 um 11:33 schrieb Holger Hoffstätte: > On 10/07/16 09:17, Wang Xiaoguang wrote: >> Hi, >> >> On 10/07/2016 03:03 PM, Stefan Priebe - P

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Hi, > > On 09/29/2016 03:27 PM, Stefan Priebe - Profihost AG wrote: >> Am 29.09.2016 um 09:13 schrieb Wang Xiaoguang: >>>>> I found that compress sometime report ENOSPC error even in 4.8-rc8, >>>>> currently >>>> I cannot confirm tha

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

| | | | | vmcom 2.8G | vmlim 35.1G | Greets, Stefan Am 07.10.2016 um 09:17 schrieb Wang Xiaoguang: > Hi, > > On 10/07/2016 03:03 PM, Stefan Priebe - Profihost AG wrote: >> Dear Wang, >> >> can't use v4.8.0 as i always get OOMs and total machine crashes. >> >> C

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

03:03 PM, Stefan Priebe - Profihost AG wrote: >> Dear Wang, >> >> can't use v4.8.0 as i always get OOMs and total machine crashes. >> >> Complete traces with your patch and some more btrfs patches applied (in >> the hope in fixes the OOM but it did not): >>

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Am 07.10.2016 um 10:07 schrieb Wang Xiaoguang: > hello, > > On 10/07/2016 04:06 PM, Stefan Priebe - Profihost AG wrote: >> and it shows: >> >> PAG | scan 33829e5 | steal 1968e3 | stall 0 | | >>| | swin 257071 | swo

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Am 07.10.2016 um 09:17 schrieb Wang Xiaoguang: > Hi, > > On 10/07/2016 03:03 PM, Stefan Priebe - Profihost AG wrote: >> Dear Wang, >> >> can't use v4.8.0 as i always get OOMs and total machine crashes. >> >> Complete traces with your patch and some mor

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Hi Wang, currently on the system where it's working fine - no ENOSPC error. But it will take a week to be sure they don't come back. Thanks! Greets, Stefan Am 06.10.2016 um 05:04 schrieb Wang Xiaoguang: > Hi, > > On 09/29/2016 03:27 PM, Stefan Priebe - Profihost AG wrote: >> A

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Hi Holger, Am 07.10.2016 um 11:33 schrieb Holger Hoffstätte: > On 10/07/16 09:17, Wang Xiaoguang wrote: >> Hi, >> >> On 10/07/2016 03:03 PM, Stefan Priebe - Profihost AG wrote: >>> Dear Wang, >>> >>> can't use v4.8.0 as i always get OOMs an

btrfs and systemd

Hi, i'm trying to get my 60TB btrfs volume to mount with systemd at boot. But this always fails with: "mounting timed out. Stopping." after 90s. I can't find any fstab setting for systemd to higher this timeout. There's just the x-systemd.device-timeout but this controls how long to wait for

Re: btrfs and systemd

Hi Qu, Am 29.08.2016 um 03:48 schrieb Qu Wenruo: > > > At 08/29/2016 04:15 AM, Stefan Priebe - Profihost AG wrote: >> Hi, >> >> i'm trying to get my 60TB btrfs volume to mount with systemd at boot. >> But this always fails with: "mounting timed out. St

Re: memory overflow or undeflow in free space tree / space_info?

Hi Josef, this still hapens with current 4.8-rc* releases. Anything i can do to debug this? May be insert some code to check for an under or overflow in the code? Stefan Am 14.08.2016 um 17:22 schrieb Stefan Priebe - Profihost AG: > Hi Josef, > > anything i could do or test

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Hi, Am 28.09.2016 um 14:10 schrieb Wang Xiaoguang: > OK, I see. > But given that you often run into enospc errors, can you work out a > reproduce > script according to you work load. That will give us great help. I tried hard to reproduce it but i can't get it to reproduce with a test script.

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Am 29.09.2016 um 09:13 schrieb Wang Xiaoguang: >>> I found that compress sometime report ENOSPC error even in 4.8-rc8, >>> currently >> I cannot confirm that as i do not have anough space to test this without >> compression ;-( But yes i've compression enabled. > I might not get you, my poor

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Am 29.09.2016 um 08:55 schrieb Wang Xiaoguang: > Hi, > > On 09/29/2016 02:49 PM, Stefan Priebe - Profihost AG wrote: >> Hi, >> >> Am 28.09.2016 um 14:10 schrieb Wang Xiaoguang: >>> OK, I see. >>> But given that you often run into enospc errors

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Hi, Am 29.09.2016 um 12:03 schrieb Adam Borowski: > On Thu, Sep 29, 2016 at 09:27:01AM +0200, Stefan Priebe - Profihost AG wrote: >> Am 29.09.2016 um 09:13 schrieb Wang Xiaoguang: >>>>> I found that compress sometime report ENOSPC error even in 4.8-rc8, >>>&

BTRFS: space_info 4 has 18446742286429913088 free, is not full

Dear list, is there any chance anybody wants to work with me on the following issue? BTRFS: space_info 4 has 18446742286429913088 free, is not full BTRFS: space_info total=98247376896, used=77036814336, pinned=0, reserved=0, may_use=1808490201088, readonly=0 i get this nearly every day. Here

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Am 28.09.2016 um 14:10 schrieb Wang Xiaoguang: > hello, > > On 09/28/2016 08:02 PM, Stefan Priebe - Profihost AG wrote: >> Hi Xiaoguang Wang, >> >> Am 28.09.2016 um 13:35 schrieb Wang Xiaoguang: >>> hello, >>> >>> On 09/28/2016 07:15

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Hi Xiaoguang Wang, Am 28.09.2016 um 13:35 schrieb Wang Xiaoguang: > hello, > > On 09/28/2016 07:15 PM, Stefan Priebe - Profihost AG wrote: >> Dear list, >> >> is there any chance anybody wants to work with me on the following issue? > Though I'm also somew

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Dear Holger, first thanks for your long e-mail. Am 28.09.2016 um 14:47 schrieb Holger Hoffstätte: > On 09/28/16 13:35, Wang Xiaoguang wrote: >> hello, >> >> On 09/28/2016 07:15 PM, Stefan Priebe - Profihost AG wrote: >>> Dear list, >>> >>> i

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Am 28.09.2016 um 15:44 schrieb Holger Hoffstätte: >> Good idea but it does not. I hope i can reproduce this with my already >> existing testscript which i've now bumped to use a 37TB partition and >> big files rather than a 15GB part and small files. If i can reproduce it >> i can also check

Re: deadlock with btrfs heavy i/o and kswapd

: Show Blcoked State but nothing more. Stefan Am 22.09.2016 um 16:28 schrieb Chris Mason: > > > On 09/22/2016 02:41 AM, Stefan Priebe - Profihost AG wrote: >> Hi, >> >> i always encounter btrfs deadlocks / hung tasks, when i have a lot of >> cached mem and i'm doing

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

Dear Wang, Am 06.10.2016 um 05:04 schrieb Wang Xiaoguang: > Hi, > > On 09/29/2016 03:27 PM, Stefan Priebe - Profihost AG wrote: >> Am 29.09.2016 um 09:13 schrieb Wang Xiaoguang: >>>>> I found that compress sometime report ENOSPC error even in 4.8-rc8, >>

Re: spinning kworker with space_cache=v2 searching for free space

Hello, found this one from 2014: https://patchwork.kernel.org/patch/5551651/ it this still valid? Am 09.11.2016 um 09:09 schrieb Stefan Priebe - Profihost AG: > Dear list, > > even there's a lot of free space on my disk: > > # df -h /vmbackup/ > Filesystem

spinning kworker with space_cache=v2 searching for free space

Dear list, even there's a lot of free space on my disk: # df -h /vmbackup/ FilesystemSize Used Avail Use% Mounted on /dev/mapper/stripe0-backup 37T 24T 13T 64% /backup # btrfs filesystem df /backup/ Data, single: total=23.75TiB, used=22.83TiB System, DUP:

Re: [PATCH 2/2] btrfs: fix false enospc for compression

Am 06.10.2016 um 04:51 schrieb Wang Xiaoguang: > When testing btrfs compression, sometimes we got ENOSPC error, though fs > still has much free space, xfstests generic/171, generic/172, generic/173, > generic/174, generic/175 can reveal this bug in my test environment when > compression is

Re: btrfs and numa - needing drop_caches to keep speed up

Dear julian, Am 14.10.2016 um 14:26 schrieb Julian Taylor: > On 10/14/2016 08:28 AM, Stefan Priebe - Profihost AG wrote: >> Hello list, >> >> while running the same workload on two machines (single xeon and a dual >> xeon) both with 64GB RAM. >> >> I need

Re: btrfs and numa - needing drop_caches to keep speed up

Hi, Am 14.10.2016 um 15:19 schrieb Stefan Priebe - Profihost AG: > Dear julian, > > Am 14.10.2016 um 14:26 schrieb Julian Taylor: >> On 10/14/2016 08:28 AM, Stefan Priebe - Profihost AG wrote: >>> Hello list, >>> >>> while running the same workload on two

Re: BTRFS: space_info 4 has 18446742286429913088 free, is not full

, used=155045216256, pinned=0, reserved=0, may_use=524288, readonly=65536 Greets, Stefan Am 29.09.2016 um 09:27 schrieb Stefan Priebe - Profihost AG: > Am 29.09.2016 um 09:13 schrieb Wang Xiaoguang: >>>> I found that compress sometime report ENOSPC error even in 4.8-rc8, >>>

Re: [PATCH 1/2] btrfs: improve inode's outstanding_extents computation

Hello list, just want to report again that i've seen not a single ENOSPC msg with this series applied. Now working fine since 18 days. Stefan Am 14.10.2016 um 15:09 schrieb Stefan Priebe - Profihost AG: > > Am 06.10.2016 um 04:51 schrieb Wang Xiaoguang: >> This issue was revealed

resend: Re: Btrfs: adjust len of writes if following a preallocated extent

Hi, sorry last mail was from the wrong box. Am 04.11.2016 um 20:20 schrieb Liu Bo: > If we have > > |0--hole--4095||4096--preallocate--12287| > > instead of using preallocated space, a 8K direct write will just > create a new 8K extent and it'll end up with > > |0--new

Re: resend: Re: Btrfs: adjust len of writes if following a preallocated extent

Am 23.11.2016 um 19:23 schrieb Holger Hoffstätte: > On 11/23/16 18:21, Stefan Priebe - Profihost AG wrote: >> Am 04.11.2016 um 20:20 schrieb Liu Bo: >>> If we have >>> >>> |0--hole--4095||4096--preallocate--12287| >>> >>> instead of using prea

Re: spinning kworker with space_cache=v2 searching for free space

Am 12.11.2016 um 03:18 schrieb Liu Bo: > On Wed, Nov 09, 2016 at 09:19:21PM +0100, Stefan Priebe - Profihost AG wrote: >> Hello, >> >> found this one from 2014: >> https://patchwork.kernel.org/patch/5551651/ >> >> it this still valid? > > The spac

recover btrfs with kernel 4.9-rc3 but btrfs progs fails

Hi, currently i've an fs which triggers this one on mount while originally having 50% disk free - but btrfs progs fails too. # btrfs check --repair -p /dev/vdb1 enabling repair mode couldn't open RDWR because of unsupported option features (3). ERROR: cannot open file system [ 164.378512]

btrfs and numa - needing drop_caches to keep speed up

Hello list, while running the same workload on two machines (single xeon and a dual xeon) both with 64GB RAM. I need to run echo 3 >/proc/sys/vm/drop_caches every 15-30 minutes to keep the speed as good as on the non numa system. I'm not sure whether this is related to numa. Is there any sysctl

speed up cp --reflink=always

Hello, cp --reflink=always takes sometimes very long. (i.e. 25-35 minutes) An example: source file: # ls -la vm-279-disk-1.img -rw-r--r-- 1 root root 204010946560 Oct 14 12:15 vm-279-disk-1.img target file after around 10 minutes: # ls -la vm-279-disk-1.img.tmp -rw-r--r-- 1 root root

Re: speed up cp --reflink=always

Am 16.10.2016 um 00:37 schrieb Hans van Kranenburg: > Hi, > > On 10/15/2016 10:49 PM, Stefan Priebe - Profihost AG wrote: >> >> cp --reflink=always takes sometimes very long. (i.e. 25-35 minutes) >> >> An example: >> >> source file: >> #

Re: speed up cp --reflink=always

Am 16.10.2016 um 21:48 schrieb Hans van Kranenburg: > On 10/16/2016 08:54 PM, Stefan Priebe - Profihost AG wrote: >> Am 16.10.2016 um 00:37 schrieb Hans van Kranenburg: >>> On 10/15/2016 10:49 PM, Stefan Priebe - Profihost AG wrote: >>>> >>>> cp --reflink=

Re: speed up cp --reflink=always

Am 17.10.2016 um 03:50 schrieb Qu Wenruo: > At 10/17/2016 02:54 AM, Stefan Priebe - Profihost AG wrote: >> Am 16.10.2016 um 00:37 schrieb Hans van Kranenburg: >>> Hi, >>> >>> On 10/15/2016 10:49 PM, Stefan Priebe - Profihost AG wrote: >>>> >>

Re: [PATCH 1/2] btrfs: improve inode's outstanding_extents computation

Am 06.10.2016 um 04:51 schrieb Wang Xiaoguang: > This issue was revealed by modifying BTRFS_MAX_EXTENT_SIZE(128MB) to 64KB, > When modifying BTRFS_MAX_EXTENT_SIZE(128MB) to 64KB, fsstress test often > gets these warnings from btrfs_destroy_inode(): >

Re: Metadata balance fails ENOSPC

Am 01.12.2016 um 14:51 schrieb Hans van Kranenburg: > On 12/01/2016 09:12 AM, Andrei Borzenkov wrote: >> On Thu, Dec 1, 2016 at 10:49 AM, Stefan Priebe - Profihost AG >> <s.pri...@profihost.ag> wrote: >> ... >>> >>> Custom 4.4 kernel with patches up t

Metadata balance fails ENOSPC

Hello, # btrfs balance start -v -dusage=0 -musage=1 /ssddisk/ Dumping filters: flags 0x7, state 0x0, force is off DATA (flags 0x2): balancing, usage=0 METADATA (flags 0x2): balancing, usage=1 SYSTEM (flags 0x2): balancing, usage=1 ERROR: error during balancing '/ssddisk/': No space left on

Re: Metadata balance fails ENOSPC

Am 01.12.2016 um 16:48 schrieb Chris Murphy: > On Thu, Dec 1, 2016 at 7:10 AM, Stefan Priebe - Profihost AG > <s.pri...@profihost.ag> wrote: >> >> Am 01.12.2016 um 14:51 schrieb Hans van Kranenburg: >>> On 12/01/2016 09:12 AM, Andrei Borzenkov wrote: >>>

Re: Metadata balance fails ENOSPC

isn't there a way to move free space to unallocated space again? Am 03.12.2016 um 05:43 schrieb Andrei Borzenkov: > 01.12.2016 18:48, Chris Murphy пишет: >> On Thu, Dec 1, 2016 at 7:10 AM, Stefan Priebe - Profihost AG >> <s.pri...@profihost.ag> wrote: >>> >>&

Re: Metadata balance fails ENOSPC

Am 01.12.2016 um 00:02 schrieb Chris Murphy: > On Wed, Nov 30, 2016 at 2:03 PM, Stefan Priebe - Profihost AG > <s.pri...@profihost.ag> wrote: >> Hello, >> >> # btrfs balance start -v -dusage=0 -musage=1 /ssddisk/ >> Dumping filters: flags 0x7, state 0x

Re: Metadata balance fails ENOSPC

Am 01.12.2016 um 09:12 schrieb Andrei Borzenkov: > On Thu, Dec 1, 2016 at 10:49 AM, Stefan Priebe - Profihost AG > <s.pri...@profihost.ag> wrote: > ... >> >> Custom 4.4 kernel with patches up to 4.10. But i already tried 4.9-rc7 >> which does the same. >> &

Re: [PATCH 0/3] introduce type based delalloc metadata reserve to fix some false enospc issues

//www.marc.info/?l=linux-btrfs=148338312525137=2 Stefan > Thanks, > Qu > > On 12/31/2016 03:31 PM, Stefan Priebe - Profihost AG wrote: >> Any news on this series? I can't see it in 4.9 nor in 4.10-rc >> >> Stefan >> >> Am 11.11.2016 um 09:39 schrieb Wang

Re: [PATCH 0/3] introduce type based delalloc metadata reserve to fix some false enospc issues

Any news on this series? I can't see it in 4.9 nor in 4.10-rc Stefan Am 11.11.2016 um 09:39 schrieb Wang Xiaoguang: > When having compression enabled, Stefan Priebe ofen got enospc errors > though fs still has much free space. Qu Wenruo also has submitted a > fstests test case which can

Re: [PATCH v7 1/2] btrfs: Fix metadata underflow caused by btrfs_reloc_clone_csum error

Am 13.03.2017 um 08:39 schrieb Qu Wenruo: > > > At 03/13/2017 03:26 PM, Stefan Priebe - Profihost AG wrote: >> Hi Qu, >> >> Am 13.03.2017 um 02:16 schrieb Qu Wenruo: >>> >>> At 03/13/2017 04:49 AM, Stefan Priebe - Profihost AG wrote: >>&g

Re: [PATCH v7 1/2] btrfs: Fix metadata underflow caused by btrfs_reloc_clone_csum error

Thanks Qu, removing BTRFS_I from the inode fixes this issue to me. Greets, Stefan Am 14.03.2017 um 03:50 schrieb Qu Wenruo: > > > At 03/13/2017 09:26 PM, Stefan Priebe - Profihost AG wrote: >> >> Am 13.03.2017 um 08:39 schrieb Qu Wenruo: >>> >>> &g

[PATCH v7 1/2] btrfs: Fix metadata underflow caused by btrfs_reloc_clone_csum error

Hi Qu, while V5 was running fine against the openSUSE-42.2 kernel (based on v4.4). V7 results in OOPS to me: BUG: unable to handle kernel NULL pointer dereference at 01f0 IP: [] __endio_write_update_ordered+0x33/0x140 [btrfs] PGD 14e18d4067 PUD 14e1868067 PMD 0 Oops: [#1] SMP

Re: [PATCH v7 1/2] btrfs: Fix metadata underflow caused by btrfs_reloc_clone_csum error

Hi Qu, Am 13.03.2017 um 02:16 schrieb Qu Wenruo: > > At 03/13/2017 04:49 AM, Stefan Priebe - Profihost AG wrote: >> Hi Qu, >> >> while V5 was running fine against the openSUSE-42.2 kernel (based on >> v4.4). > > Thanks for the test. > >> V7 re

  1   2   >