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

Am Mon, 10 Apr 2017 15:43:57 -0400 schrieb "Austin S. Hemmelgarn" : > On 2017-04-10 14:18, Kai Krakow wrote: > > Am Mon, 10 Apr 2017 13:13:39 -0400 > > schrieb "Austin S. Hemmelgarn" : > > > >> On 2017-04-10 12:54, Kai Krakow wrote: > [...] >

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

Am Tue, 11 Apr 2017 01:45:32 +0200 schrieb "Janos Toth F." : > >> The command-line also rejects a number of perfectly legitimate > >> arguments that BTRFS does understand too though, so that's not much > >> of a test. > > > > Which are those? I didn't encounter any...

[PATCH 5/5] btrfs-progs: fsck-check: test cases for nbytes and dir isize

Create test case '026-wrong-dir-inode-isize'. Create becon files '.lowmem_repairable' under tests/fsck-test/016 and 026. Now 'make test-fsck' will test lowmem repairable test cases if TEST_ENABLE_OVERRIDE=true. Signed-off-by: Su Yue ---

[PATCH 0/5] btrfs-progs: check: simple errors repair in lowmem

The series include following contents: 1) Repair wrong nbytes of file inode item. After traversal of extents in one file, we should get the actual nbytes of the file. If nbytes in the file inode differs from the actual value, set the value to actual one. The wrong nbytes of file

[PATCH 3/5] btrfs-progs: check: enable lowmem repair

Enable btrfsck option '--repair' with option '--mode=lowmem'. Now lowmem mode only repairs wrong nbytes, dir isize. Signed-off-by: Su Yue --- cmds-check.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/cmds-check.c b/cmds-check.c index

[PATCH 1/5] btrfs-progs: check: inode nbytes fix in lowmem

After checking one inode item, we should get the actual nbytes of the inode item. Introduce function 'repair_inode_nbytes_lowmem' to set nbytes in struct btrfs_inode_item to the actual nbytes. After call of the function, the wrong nbytes should have been corrected. Signed-off-by: Su Yue

[PATCH 2/5] btrfs-progs: check: dir isize fix in lowmem

After traversal of whole directory, we should get the actual isize. Introduce function 'repair_dir_isize_lowmem' to set isize in the directory inode item to actual size. After call of the function, the wrong dir isize should have been corrected. Signed-off-by: Su Yue

[PATCH 4/5] btrfs-progs: fsck-check: Allow fsck check test to repair in lowmem mode for certain test cases

From: Qu Wenruo Since lowmem mode can repair certain corruptions (mostly in fs tree), insert a beacon into each fsck test cases to allow some of them be tested for lowmem mode. With this patch, fsck option override will check the beacon file ".lowmem_repairbale" in the

Re: About the behavior of inline extent

At 04/11/2017 10:20 AM, Qu Wenruo wrote: At 04/10/2017 11:34 PM, David Sterba wrote: On Mon, Apr 10, 2017 at 10:17:52AM -0400, Josef Bacik wrote: On Apr 9, 2017, at 11:27 PM, Qu Wenruo wrote: Hi, Recent btrfs/137 test case makes me wonder what's the designed

Re: About the behavior of inline extent

At 04/10/2017 11:34 PM, David Sterba wrote: On Mon, Apr 10, 2017 at 10:17:52AM -0400, Josef Bacik wrote: On Apr 9, 2017, at 11:27 PM, Qu Wenruo wrote: Hi, Recent btrfs/137 test case makes me wonder what's the designed behavior of btrfs inline data extent. The

Re: [PATCH v2 8/9] btrfs: qgroup: Introduce extent changeset for qgroup reserve functions

At 04/10/2017 10:14 PM, David Sterba wrote: On Mon, Apr 10, 2017 at 04:00:25PM +0200, David Sterba wrote: On Mon, Apr 10, 2017 at 09:25:18AM +0800, Qu Wenruo wrote: At 04/07/2017 08:00 PM, David Sterba wrote: On Mon, Mar 13, 2017 at 03:52:15PM +0800, Qu Wenruo wrote: @@ -3355,12 +3355,14

[PATCH] btrfs-progs: send-dump: always print a space after path

I was shocked to discover that 'btrfs receive --dump' doesn't print a space after long filenames, so it runs together into the metadata; for example: truncate./20-00-03/this-name-is-32-characters-longsize=0 This is a trivial patch to add a single space unconditionally, so the result is

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

>> The command-line also rejects a number of perfectly legitimate >> arguments that BTRFS does understand too though, so that's not much >> of a test. > > Which are those? I didn't encounter any... I think this bug still stands unresolved (for 3+ years, probably because most people use init-rd/fs

Re: About free space fragmentation, metadata write amplification and (no)ssd

On 04/10/2017 02:23 PM, Austin S. Hemmelgarn wrote: > On 2017-04-08 16:19, Hans van Kranenburg wrote: >> So... today a real life story / btrfs use case example from the trenches >> at work... >> >> tl;dr 1) btrfs is awesome, but you have to carefully choose which parts >> of it you want to use or

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

On Mon, Apr 10, 2017 at 03:43:57PM -0400, Austin S. Hemmelgarn wrote: > On 2017-04-10 14:18, Kai Krakow wrote: > * strictatime, lazytime: Both atime and mtime updates happen, but they > actual update may not hit the disk for up to 24 hours (this will let mutt > work correctly as long as your

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

On 2017-04-10 14:18, Kai Krakow wrote: Am Mon, 10 Apr 2017 13:13:39 -0400 schrieb "Austin S. Hemmelgarn" : On 2017-04-10 12:54, Kai Krakow wrote: Am Mon, 10 Apr 2017 18:44:44 +0200 schrieb Kai Krakow : Am Mon, 10 Apr 2017 08:51:38 -0400 schrieb

[PATCH] Btrfs: fix potential use-after-free for cloned bio

KASAN reports that there is a use-after-free case of bio in btrfs_map_bio. If we need to submit IOs to several disks at a time, the original bio would get cloned and mapped to the destination disk, but we really should use the original bio instead of a cloned bio to do the sanity check because

Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division

On Sat, Apr 08, 2017 at 11:07:37PM +0200, Adam Borowski wrote: > Unbreaks ARM and possibly other 32-bit architectures. > Thanks a lot for the fix. Reviewed-by: Liu Bo Thanks, -liubo > Fixes: 7d0ef8b4d: Btrfs: update scrub_parity to use u64 stripe_len > Reported-by:

Re: [PATCH] Btrfs: fix segment fault when doing dio read

On Sun, Apr 09, 2017 at 08:08:05PM +0300, Nikolay Borisov wrote: > > > On 7.04.2017 23:11, Liu Bo wrote: > > Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized blocks") > > introduced this bug during iterating bio pages in dio read's endio hook, > > and it could end up with

Re: BUG: KASAN: use-after-free in btrfs_map_bio

On Mon, Apr 10, 2017 at 07:13:46PM +0200, Diego wrote: > In the latest git, with KASAN enabled: > > [ 180.560145] BUG: KASAN: use-after-free in btrfs_map_bio+0x994/0x10b0 at > addr 8803801a76fc > [ 180.560151] Read of size 4 by task localStorage DB/924 > [ 180.560160] CPU: 0 PID: 924

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

Am Mon, 10 Apr 2017 13:13:39 -0400 schrieb "Austin S. Hemmelgarn" : > On 2017-04-10 12:54, Kai Krakow wrote: > > Am Mon, 10 Apr 2017 18:44:44 +0200 > > schrieb Kai Krakow : > > > >> Am Mon, 10 Apr 2017 08:51:38 -0400 > >> schrieb "Austin S.

Re: [PATCH v2] btrfs: drop the nossd flag when remounting with -o ssd

On Tue, Apr 04, 2017 at 12:43:57AM +0200, Hans van Kranenburg wrote: > On 04/03/2017 02:24 PM, David Sterba wrote: > > On Fri, Mar 31, 2017 at 10:24:57PM +0200, Hans van Kranenburg wrote: > Adding the 'nossd_spread' would be good to have, even if it might be > just a marginal usecase. >

Re: [PATCH] btrfs-progs: Fix missing newline in man 5 btrfs

On Sun, Apr 09, 2017 at 12:37:47AM +0200, Hans van Kranenburg wrote: > The text compress_lzo:: would show up directly after 'bigger than the > page size' on the same line. Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to

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

On 2017-04-10 12:54, Kai Krakow wrote: Am Mon, 10 Apr 2017 18:44:44 +0200 schrieb Kai Krakow : Am Mon, 10 Apr 2017 08:51:38 -0400 schrieb "Austin S. Hemmelgarn" : On 2017-04-10 08:45, Kai Krakow wrote: Am Mon, 10 Apr 2017 08:39:23 -0400 schrieb

BUG: KASAN: use-after-free in btrfs_map_bio

In the latest git, with KASAN enabled: [ 180.560145] BUG: KASAN: use-after-free in btrfs_map_bio+0x994/0x10b0 at addr 8803801a76fc [ 180.560151] Read of size 4 by task localStorage DB/924 [ 180.560160] CPU: 0 PID: 924 Comm: localStorage DB Not tainted 4.11.0-rc6-g39da7c509acf #19 [

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

Am Mon, 10 Apr 2017 18:44:44 +0200 schrieb Kai Krakow : > Am Mon, 10 Apr 2017 08:51:38 -0400 > schrieb "Austin S. Hemmelgarn" : > > > On 2017-04-10 08:45, Kai Krakow wrote: > > > Am Mon, 10 Apr 2017 08:39:23 -0400 > > > schrieb "Austin S. Hemmelgarn"

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

Am Mon, 10 Apr 2017 08:51:38 -0400 schrieb "Austin S. Hemmelgarn" : > On 2017-04-10 08:45, Kai Krakow wrote: > > Am Mon, 10 Apr 2017 08:39:23 -0400 > > schrieb "Austin S. Hemmelgarn" : > > > >> They've been running BTRFS > >> with LZO compression, the

Re: [PATCH] Btrfs: fix segment fault when doing dio read

On Sun, Apr 09, 2017 at 08:08:05PM +0300, Nikolay Borisov wrote: > > > On 7.04.2017 23:11, Liu Bo wrote: > > Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized blocks") > > introduced this bug during iterating bio pages in dio read's endio hook, > > and it could end up with

Re: About the behavior of inline extent

On Mon, Apr 10, 2017 at 10:17:52AM -0400, Josef Bacik wrote: > > > On Apr 9, 2017, at 11:27 PM, Qu Wenruo wrote: > > > > Hi, > > > > Recent btrfs/137 test case makes me wonder what's the designed behavior of > > btrfs inline data extent. > > > > The current behavior

Re: [PATCH 6/8] nowait aio: ext4

On Mon 10-04-17 07:39:43, Christoph Hellwig wrote: > On Mon, Apr 10, 2017 at 02:37:50PM +0200, Jan Kara wrote: > > I don't understand here. Do you want that all filesystems support NOWAIT > > direct IO? > > No. Per-file_system_type is way to coarse grained. All feature flag > needs to be

Re: [PATCH 6/8] nowait aio: ext4

On Mon, Apr 10, 2017 at 02:37:50PM +0200, Jan Kara wrote: > I don't understand here. Do you want that all filesystems support NOWAIT > direct IO? No. Per-file_system_type is way to coarse grained. All feature flag needs to be per-file_operation at least for cases like ext4 with our without

Re: About the behavior of inline extent

> On Apr 9, 2017, at 11:27 PM, Qu Wenruo wrote: > > Hi, > > Recent btrfs/137 test case makes me wonder what's the designed behavior of > btrfs inline data extent. > > The current behavior in fact is quite a chaos. > We need a standard of how inline extent should

Re: [PATCH v2 8/9] btrfs: qgroup: Introduce extent changeset for qgroup reserve functions

On Mon, Apr 10, 2017 at 04:00:25PM +0200, David Sterba wrote: > On Mon, Apr 10, 2017 at 09:25:18AM +0800, Qu Wenruo wrote: > > > > > > At 04/07/2017 08:00 PM, David Sterba wrote: > > > On Mon, Mar 13, 2017 at 03:52:15PM +0800, Qu Wenruo wrote: > > >> @@ -3355,12 +3355,14 @@ static int

Re: [PATCH v2 8/9] btrfs: qgroup: Introduce extent changeset for qgroup reserve functions

On Mon, Apr 10, 2017 at 09:25:18AM +0800, Qu Wenruo wrote: > > > At 04/07/2017 08:00 PM, David Sterba wrote: > > On Mon, Mar 13, 2017 at 03:52:15PM +0800, Qu Wenruo wrote: > >> @@ -3355,12 +3355,14 @@ static int cache_save_setup(struct > >> btrfs_block_group_cache *block_group, > >>struct

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

On 2017-04-10 08:45, Kai Krakow wrote: Am Mon, 10 Apr 2017 08:39:23 -0400 schrieb "Austin S. Hemmelgarn" : They've been running BTRFS with LZO compression, the SSD allocator, atime disabled, and mtime updates deferred (lazytime mount option) the whole time, so it may be a

Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division

On 2017-04-08 17:07, Adam Borowski wrote: Unbreaks ARM and possibly other 32-bit architectures. Fixes: 7d0ef8b4d: Btrfs: update scrub_parity to use u64 stripe_len Reported-by: Icenowy Zheng Signed-off-by: Adam Borowski --- You'd probably want to squash

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

Am Mon, 10 Apr 2017 08:39:23 -0400 schrieb "Austin S. Hemmelgarn" : > They've been running BTRFS > with LZO compression, the SSD allocator, atime disabled, and mtime > updates deferred (lazytime mount option) the whole time, so it may be > a slightly different use case

Re: parity scrub on 32-bit

On 2017-04-10 04:53, Adam Borowski wrote: Hi! While messing with the division failure on current -next, I've noticed that parity scrub splats immediately on all 32-bit archs I tried. But, it's not a regression: it bisects to 5a6ac9eacb49143cbad3bbfda72263101cb1f3df (merged in 3.19) which

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

On 2017-04-09 19:23, Hans van Kranenburg wrote: On 04/08/2017 01:16 PM, Hans van Kranenburg wrote: On 04/07/2017 11:25 PM, Hans van Kranenburg wrote: Ok, I'm going to revive a year old mail thread here with interesting new info: [...] Now, another surprise: From the exact moment I did mount

Re: [PATCH 6/8] nowait aio: ext4

On Mon 10-04-17 00:45:39, Christoph Hellwig wrote: > On Tue, Apr 04, 2017 at 01:41:09PM -0500, Goldwyn Rodrigues wrote: > > I am working on incorporating RWF_* flags. However, I am not sure how > > RWF_* flags would get rid of FS_NOWAIT/FS_NOWAIT_IO. Since most of > > "blocking" information is

Re: About free space fragmentation, metadata write amplification and (no)ssd

On 2017-04-08 16:19, Hans van Kranenburg wrote: So... today a real life story / btrfs use case example from the trenches at work... tl;dr 1) btrfs is awesome, but you have to carefully choose which parts of it you want to use or avoid 2) improvements can be made, but at least the problems

Re: linux-next: Tree for Apr 7 (btrfs)

On Fri, Apr 07, 2017 at 06:05:02PM +0200, David Sterba wrote: > On Fri, Apr 07, 2017 at 08:10:48AM -0700, Randy Dunlap wrote: > > On 04/07/17 08:08, Randy Dunlap wrote: > > > On 04/07/17 01:27, Stephen Rothwell wrote: > > >> Hi all, > > >> > > >> Changes since 20170406: > > >> > > > > > > on

Re: Volume appears full but TB's of space available

On 2017-04-08 01:12, Duncan wrote: Austin S. Hemmelgarn posted on Fri, 07 Apr 2017 07:41:22 -0400 as excerpted: 2. Results from 'btrfs scrub'. This is somewhat tricky because scrub is either asynchronous or blocks for a _long_ time. The simplest option I've found is to fire off an

Re: [PATCH] btrfs: scrub: use do_div() for 64-by-32 division

On Sat, Apr 08, 2017 at 11:07:37PM +0200, Adam Borowski wrote: > Unbreaks ARM and possibly other 32-bit architectures. > > Fixes: 7d0ef8b4d: Btrfs: update scrub_parity to use u64 stripe_len > Reported-by: Icenowy Zheng > Signed-off-by: Adam Borowski > --- >

Re: BTRFS not mountable, recover won't work

On Mon, 2017-04-10 at 16:53 +0800, Qu Wenruo wrote: > > Then try chunk recovery > -- >   btrfs rescue chunk-recover /dev/dm-0 > -- > > It can be very slow since it may scan the full device. > > Thanks, > Qu > > > > Thanks, > > > Qu > > > > Thank you > > Thank you for your help this

Re: BTRFS not mountable, recover won't work

At 04/10/2017 04:37 PM, Malte Eggers wrote: On Mon, 2017-04-10 at 16:18 +0800, Qu Wenruo wrote: At 04/10/2017 01:17 AM, Malte Eggers wrote: Hi, After suspending and waking up my laptop with the external hard drive connected, I could no longer access the files on it. So I unmounted and

parity scrub on 32-bit

Hi! While messing with the division failure on current -next, I've noticed that parity scrub splats immediately on all 32-bit archs I tried. But, it's not a regression: it bisects to 5a6ac9eacb49143cbad3bbfda72263101cb1f3df (merged in 3.19) which happens to be when parity scrub was added. Ie, it

Re: BTRFS not mountable, recover won't work

On Mon, 2017-04-10 at 16:18 +0800, Qu Wenruo wrote: > > At 04/10/2017 01:17 AM, Malte Eggers wrote: > > Hi, > > > > After suspending and waking up my laptop with the external hard > > drive > > connected, I could no longer access the files on it. So I unmounted > > and > > remounted it, only to

Re: BTRFS not mountable, recover won't work

At 04/10/2017 01:17 AM, Malte Eggers wrote: Hi, After suspending and waking up my laptop with the external hard drive connected, I could no longer access the files on it. So I unmounted and remounted it, only to discover that I could no longer mount it. This is the error (mounting with

Re: BTRFS not mountable, recover won't work

On Sun, 2017-04-09 at 15:25 -0600, Chris Murphy wrote: > On Sun, Apr 9, 2017 at 11:17 AM, Malte Eggers > wrote: > > Hi, > > > > After suspending and waking up my laptop with the external hard > > drive > > connected, I could no longer access the files on it. So I

Re: [PATCH 6/8] nowait aio: ext4

On Tue, Apr 04, 2017 at 01:41:09PM -0500, Goldwyn Rodrigues wrote: > I am working on incorporating RWF_* flags. However, I am not sure how > RWF_* flags would get rid of FS_NOWAIT/FS_NOWAIT_IO. Since most of > "blocking" information is with the filesystem, it is a per-filesystem > flag to block