Re: Bad hard drive - checksum verify failure forces readonly mount

On Thu, Jun 23, 2016 at 10:56 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Chris Murphy posted on Thu, 23 Jun 2016 18:54:28 -0600 as excerpted: > >> From the pasted kernel messages: >> >>> Linux version 3.18.34-std473-amd64 (root@rl-sysrcd-p11) (gcc version >>> 4.8.5 (Gentoo 4.8.5 p1.3, pie-0.6.2) )

Re: Adventures in btrfs raid5 disk recovery

On Thu, Jun 23, 2016 at 8:07 PM, Zygo Blaxell wrote: >> With simple files changing one character with vi and gedit, >> I get completely different logical and physical numbers with each >> change, so it's clearly cowing the entire stripe (192KiB in my 3 dev >>

Re: Bad hard drive - checksum verify failure forces readonly mount

Chris Murphy posted on Thu, 23 Jun 2016 18:54:28 -0600 as excerpted: > From the pasted kernel messages: > >> Linux version 3.18.34-std473-amd64 (root@rl-sysrcd-p11) (gcc version >> 4.8.5 (Gentoo 4.8.5 p1.3, pie-0.6.2) ) #2 SMP Tue May 24 20:34:19 UTC >> 2016 > > > 3.18.34 is ancient. Find

Re: [PATCH v11 00/13] Btrfs dedupe framework

On Friday, June 24, 2016 10:50:41 AM Qu Wenruo wrote: > Hi Chandan, David, > > When I'm trying to rebase dedupe patchset on top of Chadan's sub page > size patchset (using David's for-next-test-20160620), although the > rebase itself is quite simple, but I'm afraid that I found some bugs for >

Re: [PATCH v11 00/13] Btrfs dedupe framework

On Thursday, June 23, 2016 02:17:38 PM David Sterba wrote: > On Tue, Jun 21, 2016 at 10:25:19PM +0530, Chandan Rajendra wrote: > > > > I'm completely OK to do the rebase, but since I don't have 64K page > > > > size > > > > machine to test the rebase, we can only test if 4K system is unaffected.

Re: Adventures in btrfs raid5 disk recovery

24.06.2016 04:47, Zygo Blaxell пишет: > On Thu, Jun 23, 2016 at 06:26:22PM -0600, Chris Murphy wrote: >> On Thu, Jun 23, 2016 at 1:32 PM, Goffredo Baroncelli >> wrote: >>> The raid5 write hole is avoided in BTRFS (and in ZFS) thanks to the >>> checksum. >> >> Yeah I'm kinda

Re: btrfs-progs 4.6 won't build on CentOS6

On 2016-06-24 13:22, Eric Sandeen wrote: On 6/23/16 8:49 PM, Steven Haigh wrote: I've tried to build the new tools for CentOS 6 / Scientific Linux 6 / RHEL 6 etc. During the build process, I see: cmds-fi-du.c: In function 'du_calc_file_space': cmds-fi-du.c:330: error: 'FIEMAP_EXTENT_SHARED'

Re: btrfs-progs 4.6 won't build on CentOS6

At 06/24/2016 11:22 AM, Eric Sandeen wrote: On 6/23/16 8:49 PM, Steven Haigh wrote: I've tried to build the new tools for CentOS 6 / Scientific Linux 6 / RHEL 6 etc. During the build process, I see: cmds-fi-du.c: In function 'du_calc_file_space': cmds-fi-du.c:330: error:

Re: btrfs-progs 4.6 won't build on CentOS6

On 6/23/16 8:49 PM, Steven Haigh wrote: > I've tried to build the new tools for CentOS 6 / Scientific Linux 6 / RHEL 6 > etc. > > During the build process, I see: > cmds-fi-du.c: In function 'du_calc_file_space': > cmds-fi-du.c:330: error: 'FIEMAP_EXTENT_SHARED' undeclared (first use in this >

Re: [PATCH v11 00/13] Btrfs dedupe framework

Hi Chandan, David, When I'm trying to rebase dedupe patchset on top of Chadan's sub page size patchset (using David's for-next-test-20160620), although the rebase itself is quite simple, but I'm afraid that I found some bugs for sub page size patchset, *without* dedupe patchset applied.

fstests generic/068 hang 120seconds

hello, When running generic/068 in linux mail line tree 4.7.rc4, we found that sometimes there are processes hang 120 seconds WARNINGs, it seems that some deadlocks occurs, please see the attachment. Also it seems 4.4.0-rc6+ has this issue. Note, this bug was not reproduced every time, you need

Re: Adventures in btrfs raid5 disk recovery

On Thu, Jun 23, 2016 at 05:37:09PM -0600, Chris Murphy wrote: > > I expect that parity is in this data block group, and therefore is > > checksummed the same as any other data in that block group. > > This appears to be wrong. Comparing the same file, one file only, one > two new Btrfs volumes,

Re: Adventures in btrfs raid5 disk recovery

On Thu, Jun 23, 2016 at 05:37:09PM -0600, Chris Murphy wrote: > > So in your example of degraded writes, no matter what the on disk > > format makes it discoverable there is a problem: > > > > A. The "updating" is still always COW so there is no overwriting. > > There is RMW code in

Re: btrfs-progs 4.6 won't build on CentOS6

On 6/23/16 9:49 PM, Steven Haigh wrote: > I've tried to build the new tools for CentOS 6 / Scientific Linux 6 / > RHEL 6 etc. > > During the build process, I see: > cmds-fi-du.c: In function 'du_calc_file_space': > cmds-fi-du.c:330: error: 'FIEMAP_EXTENT_SHARED' undeclared (first use in > this

btrfs-progs 4.6 won't build on CentOS6

I've tried to build the new tools for CentOS 6 / Scientific Linux 6 / RHEL 6 etc. During the build process, I see: cmds-fi-du.c: In function 'du_calc_file_space': cmds-fi-du.c:330: error: 'FIEMAP_EXTENT_SHARED' undeclared (first use in this function) cmds-fi-du.c:330: error: (Each undeclared

Re: Adventures in btrfs raid5 disk recovery

On Thu, Jun 23, 2016 at 06:26:22PM -0600, Chris Murphy wrote: > On Thu, Jun 23, 2016 at 1:32 PM, Goffredo Baroncelli > wrote: > > The raid5 write hole is avoided in BTRFS (and in ZFS) thanks to the > > checksum. > > Yeah I'm kinda confused on this point. > >

Re: Adventures in btrfs raid5 disk recovery

On Thu, Jun 23, 2016 at 09:32:50PM +0200, Goffredo Baroncelli wrote: > The raid write hole happens when a stripe is not completely written > on the platters: the parity and the related data mismatch. In this > case a "simple" raid5 may return wrong data if the parity is used to > compute the data.

Re: system crash on replace

On 2016-06-24 05:13, Scott Talbert wrote: On Thu, 23 Jun 2016, Steven Haigh wrote: On 24/06/16 04:35, Austin S. Hemmelgarn wrote: On 2016-06-23 13:44, Steven Haigh wrote: Hi all, Relative newbie to BTRFS, but long time linux user. I pass the full disks from a Xen Dom0 -> guest DomU and run

Re: Bad hard drive - checksum verify failure forces readonly mount

On Thu, Jun 23, 2016 at 2:30 PM, Vasco Almeida wrote: > I was running OpenSuse Leap 42.1 with btrfs and > LVM (Logical Volume Management). > Last time I've checked smartd log, I noticed there were > 30 sector pending reallocation and 1 unrecoverable bad > sector on hard

Re: Adventures in btrfs raid5 disk recovery

On Thu, Jun 23, 2016 at 1:32 PM, Goffredo Baroncelli wrote: > > The raid5 write hole is avoided in BTRFS (and in ZFS) thanks to the checksum. Yeah I'm kinda confused on this point. https://btrfs.wiki.kernel.org/index.php/RAID56 It says there is a write hole for Btrfs. But

Re: Adventures in btrfs raid5 disk recovery

On Wed, Jun 22, 2016 at 11:14 AM, Chris Murphy wrote: > > However, from btrfs-debug-tree from a 3 device raid5 volume: > > item 5 key (FIRST_CHUNK_TREE CHUNK_ITEM 1103101952) itemoff 15621 itemsize 144 > chunk length 2147483648 owner 2 stripe_len 65536 > type DATA|RAID5

Re: Hello world, python-btrfs

Hi, On 06/23/2016 04:26 PM, David Sterba wrote: On Sat, Jun 18, 2016 at 12:01:53AM +0200, Hans van Kranenburg wrote: proof-of-concept level scripts to be able to debug my btrfs file systems, the inevitable happened: https://github.com/knorrie/python-btrfs/ Currently, the primary goal of this

[PATCH v2] Btrfs: error out if generic_bin_search get invalid arguments

With btrfs-corrupt-block, one can set btree node/leaf's field, if we assign a negative value to node/leaf, we can get various hangs, eg. if extent_root's nritems is -2ULL, then we get stuck in btrfs_read_block_groups() because it has a while loop and btrfs_search_slot() on extent_root will always

Re: [PATCH 0/3] btrfs-progs: check improve 'checking extents' scalability

On 6/23/16 5:24 PM, Holger Hoffstätte wrote: > On 06/23/16 21:26, je...@suse.com wrote: >> From: Jeff Mahoney Hi Holger - >> While running xfstests generic/291, which creates a single file populated Whoops, this should've been generic/297. >> with reflinks to the same extent,

Re: [PATCH 0/3] btrfs-progs: check improve 'checking extents' scalability

On 06/23/16 21:26, je...@suse.com wrote: > From: Jeff Mahoney > > While running xfstests generic/291, which creates a single file populated > with reflinks to the same extent, I found that fsck had been running for > hours. perf top lead me to find_data_backref as the culprit,

Bad hard drive - checksum verify failure forces readonly mount

I was running OpenSuse Leap 42.1 with btrfs and LVM (Logical Volume Management). Last time I've checked smartd log, I noticed there were 30 sector pending reallocation and 1 unrecoverable bad sector on hard drive. I think my hard drive got some sector corrupted and now btrfs fails some checksum

Re: Adventures in btrfs raid5 disk recovery

On 2016-06-22 22:35, Zygo Blaxell wrote: >> I do not know the exact nature of the Btrfs raid56 write hole. Maybe a >> > dev or someone who knows can explain it. > If you have 3 raid5 devices, they might be laid out on disk like this > (e.g. with a 16K stripe width): > > Address: 0..16K

[PATCH 0/3] btrfs-progs: check improve 'checking extents' scalability

From: Jeff Mahoney While running xfstests generic/291, which creates a single file populated with reflinks to the same extent, I found that fsck had been running for hours. perf top lead me to find_data_backref as the culprit, and a litte more digging made it clear: For every

[PATCH 2/3] btrfs-progs: check: supplement extent backref list with rbtree

From: Jeff Mahoney For the pathlogical case, like xfstests generic/297 that creates a large file consisting of one, repeating reflinked extent, fsck can take hours. The root cause is that calling find_data_backref while iterating the extent records is an O(n^2) algorithm. For

[PATCH 1/3] btrfs-progs: check: add helpers for converting between structures

From: Jeff Mahoney We either open code list_entry calls or outright cast between types. The compiler will do the right thing if we use static inlines to do typesafe conversions. Signed-off-by: Jeff Mahoney --- cmds-check.c | 100

[PATCH 3/3] btrfs-progs: check: switch to iterating over the backref_tree

From: Jeff Mahoney We now have two data structures that can be used to iterate the same data set, and there may be quite a few of them in memory. Eliminating the list_head member will reduce memory consumption while iterating over the extent backrefs. Signed-off-by: Jeff

Re: system crash on replace

On Thu, 23 Jun 2016, Steven Haigh wrote: On 24/06/16 04:35, Austin S. Hemmelgarn wrote: On 2016-06-23 13:44, Steven Haigh wrote: Hi all, Relative newbie to BTRFS, but long time linux user. I pass the full disks from a Xen Dom0 -> guest DomU and run BTRFS within the DomU. I've migrated my

Re: system crash on replace

On 24/06/16 04:35, Austin S. Hemmelgarn wrote: > On 2016-06-23 13:44, Steven Haigh wrote: >> Hi all, >> >> Relative newbie to BTRFS, but long time linux user. I pass the full >> disks from a Xen Dom0 -> guest DomU and run BTRFS within the DomU. >> >> I've migrated my existing mdadm RAID6 to a

Re: system crash on replace

On 2016-06-23 13:44, Steven Haigh wrote: Hi all, Relative newbie to BTRFS, but long time linux user. I pass the full disks from a Xen Dom0 -> guest DomU and run BTRFS within the DomU. I've migrated my existing mdadm RAID6 to a BTRFS raid6 layout. I have a drive that threw a few UNC errors

Re: [PULL] Btrfs updates for 4.7-rc5

On 06/23/2016 06:56 AM, David Sterba wrote: Hi, this is hopefully the last pull for 4.7 from me. There are two fixes that should finalize the changes introduced in this dev cycle, plus some minor independent fixes. The following changes since commit 33688abb2802ff3a230bd2441f765477b94cc89e:

[PATCH] btrfs: Fix slab accounting flags

BTRFS is using a variety of slab caches to satisfy internal needs. Those slab caches are always allocated with the SLAB_RECLAIM_ACCOUNT, meaning allocations from the caches are going to be accounted as SReclaimable. At the same time btrfs is not registering any shrinkers whatsoever, thus

system crash on replace

Hi all, Relative newbie to BTRFS, but long time linux user. I pass the full disks from a Xen Dom0 -> guest DomU and run BTRFS within the DomU. I've migrated my existing mdadm RAID6 to a BTRFS raid6 layout. I have a drive that threw a few UNC errors during a subsequent balance, so I've pulled

Re: [PATCH] Btrfs: fix BUG_ON in btrfs_submit_compressed_write

On Thu, Jun 23, 2016 at 11:09:52AM +0200, David Sterba wrote: > On Wed, Jun 22, 2016 at 06:32:06PM -0700, Liu Bo wrote: > > This is similar to btrfs_submit_compressed_read(), if we fail after > > bio is allocated, then we can use bio_endio() and errors are saved > > in bio->bi_error. But please

Re: [PATCH] Btrfs: error out if generic_bin_search get invalid arguments

On Thu, Jun 23, 2016 at 10:51:52AM +0200, David Sterba wrote: > On Wed, Jun 22, 2016 at 06:32:19PM -0700, Liu Bo wrote: > > With btrfs-corrupt-block, one can set btree node/leaf's field, if > > we assign a negative value to node/leaf, we can get various hangs, > > eg. if extent_root's nritems is

Re: Scrub not fixing checksum errors on RAID6

Jussi Kansanen posted on Thu, 23 Jun 2016 18:17:46 +0300 as excerpted: > Scrub found some checksum errors on my RAID6, errors are said to be > fixed but every scrub results in identical errors. Any ideas why this is > happening? The HDD seems to be working OK, no IO errors, no SMART errors > and

Scrub not fixing checksum errors on RAID6

Hello, Scrub found some checksum errors on my RAID6, errors are said to be fixed but every scrub results in identical errors. Any ideas why this is happening? The HDD seems to be working OK, no IO errors, no SMART errors and it passed SMART long-test. Latest scrub was run with 4.6.2 kernel & 4.6

Re: [PATCH v3 2/2] btrfs: make sure device is synced before return

On 06/23/2016 08:54 AM, Anand Jain wrote: An inconsistent behavior due to stale reads from the disk was reported mail-archive.com/linux-btrfs@vger.kernel.org/msg54188.html This patch will make sure devices are synced before return in the unmount thread. Signed-off-by: Anand Jain

Re: Hello world, python-btrfs

On Sat, Jun 18, 2016 at 12:01:53AM +0200, Hans van Kranenburg wrote: > proof-of-concept level scripts to be able to debug my btrfs file > systems, the inevitable happened: > > https://github.com/knorrie/python-btrfs/ > > Currently, the primary goal of this module is to be able to inspect the >

[PATCH v3 2/6] fstests: btrfs: add functions to get and put a device for replace target

From: Anand Jain For the replace tests we need a device as a spare device, here functions _spare_dev_get() and _spare_dev_put() will get it from the SCRATCH_DEV_POOL_SAVED, which is set when _scratch_dev_pool_get() is called, and is based on how many has already been

Re: [RFC][PATCH] btrfs-progs: inspect: new subcommand to dump chunks

On Thu, Jun 23, 2016 at 03:10:09AM +0200, Hans van Kranenburg wrote: > On 06/22/2016 07:26 PM, David Sterba wrote: > > From: David Sterba > > > > Hi, > > > > the chunk dump is a useful thing, for debugging or balance filters. > > > > Example output: > > > > Chunks on device id: 1

[PATCH v3 1/6] fstests: btrfs: add functions to set and reset required number of SCRATCH_DEV_POOL

From: Anand Jain This patch provides functions _scratch_dev_pool_get() _scratch_dev_pool_put() Which will help to set/reset SCRATCH_DEV_POOL with the required number of devices. SCRATCH_DEV_POOL_SAVED will hold all the devices. Usage: _scratch_dev_pool_get() :: do

Re: [RFC][PATCH] btrfs-progs: inspect: new subcommand to dump chunks

On 06/23/2016 03:13 PM, David Sterba wrote: On Thu, Jun 23, 2016 at 12:20:38AM +0200, Hans van Kranenburg wrote: Printing 'usage' is not default as it's quite slow, it uses the search ioctl and probably not in the best way, or there's some other issue in the implementation. Interesting. So

[PATCH v3] fstests: btrfs: fix 006

btrfs fi sync /mnt, now does not output anything for success, so the 006.out should be updated. This change in btrfs-progs was introduced in the commit b005ca024990569d2de459485682158633937928 btrfs-progs: fi sync: make it silent by default which was integrated at btrfs-progs version v4.5.2

Re: [RFC][PATCH] btrfs-progs: inspect: new subcommand to dump chunks

On Thu, Jun 23, 2016 at 12:20:38AM +0200, Hans van Kranenburg wrote: > > Printing 'usage' is not default as it's quite slow, it uses the search ioctl > > and probably not in the best way, or there's some other issue in the > > implementation. > > Interesting. > > So after reading this, I wrote a

Re: [RFC][PATCH] btrfs-progs: inspect: new subcommand to dump chunks

On Thu, Jun 23, 2016 at 09:20:40AM +0800, Qu Wenruo wrote: > Yes, quite useful. > I don't ever need to manually check btrfs-debug-tree output to figure > out the dev-extent layout. > > But according to the output, it's more like dev-extent dump, not chunk dump. > > It's better to make things

Re: [PATCH v2 2/2] btrfs: wait for bdev put

On 06/23/2016 05:47 AM, Chris Mason wrote: On Wed, Jun 22, 2016 at 6:18 AM, Anand Jain wrote: Thanks for the review Chris. On 06/21/2016 09:00 PM, Chris Mason wrote: On 06/21/2016 06:24 AM, Anand Jain wrote: From: Anand Jain Further to

[PATCH RFC] don't background blkdev_put()

As of now we are calling blkdev_put() under call_rcu, actually which isn't necessary. Unless I am missing something. This is a try out patch to know the same. Ran successfully the fstests. This should be applied on top of recent other patches, [PATCH 1/2] btrfs: reorg btrfs_close_one_device()

[PATCH v3 2/2] btrfs: make sure device is synced before return

An inconsistent behavior due to stale reads from the disk was reported mail-archive.com/linux-btrfs@vger.kernel.org/msg54188.html This patch will make sure devices are synced before return in the unmount thread. Signed-off-by: Anand Jain --- v2: Also to make sure

Re: [RFC][PATCH] btrfs-progs: inspect: new subcommand to dump chunks

On Wed, Jun 22, 2016 at 06:53:52PM -0700, Liu Bo wrote: > > +static u64 fill_usage(int fd, u64 lstart) > > +{ > > + struct btrfs_ioctl_search_args args; > > + struct btrfs_ioctl_search_key *sk = > > + struct btrfs_ioctl_search_header sh; > > + struct btrfs_block_group_item *item; > > +

Re: [PATCH v2] fstests: btrfs: fix 006 adds _runnt_btrfs_util_prog()

On 06/23/2016 08:11 PM, Eryu Guan wrote: On Thu, Jun 23, 2016 at 07:34:49PM +0800, Anand Jain wrote: On 06/23/2016 07:18 PM, Eryu Guan wrote: On Thu, Jun 23, 2016 at 07:03:59PM +0800, Anand Jain wrote: On 06/23/2016 06:53 PM, Eryu Guan wrote: [snip] diff --git a/common/rc b/common/rc

Re: [PATCH v11 00/13] Btrfs dedupe framework

On Tue, Jun 21, 2016 at 10:25:19PM +0530, Chandan Rajendra wrote: > > > I'm completely OK to do the rebase, but since I don't have 64K page size > > > machine to test the rebase, we can only test if 4K system is unaffected. > > > > > > Although not much help, at least it would be better than

Re: [PATCH v2] fstests: btrfs: fix 006 adds _runnt_btrfs_util_prog()

On Thu, Jun 23, 2016 at 07:34:49PM +0800, Anand Jain wrote: > > > On 06/23/2016 07:18 PM, Eryu Guan wrote: > > On Thu, Jun 23, 2016 at 07:03:59PM +0800, Anand Jain wrote: > > > > > > > > > On 06/23/2016 06:53 PM, Eryu Guan wrote: > > [snip] > > > > > diff --git a/common/rc b/common/rc > > > >

Re: [PATCH v2] fstests: btrfs: fix 006 adds _runnt_btrfs_util_prog()

On 06/23/2016 07:54 PM, Filipe Manana wrote: On Thu, Jun 23, 2016 at 12:34 PM, Anand Jain wrote: On 06/23/2016 07:18 PM, Eryu Guan wrote: On Thu, Jun 23, 2016 at 07:03:59PM +0800, Anand Jain wrote: On 06/23/2016 06:53 PM, Eryu Guan wrote: [snip] diff --git

Re: [PATCH v2] fstests: btrfs: fix 006 adds _runnt_btrfs_util_prog()

On Thu, Jun 23, 2016 at 12:34 PM, Anand Jain wrote: > > > On 06/23/2016 07:18 PM, Eryu Guan wrote: >> >> On Thu, Jun 23, 2016 at 07:03:59PM +0800, Anand Jain wrote: >>> >>> >>> >>> On 06/23/2016 06:53 PM, Eryu Guan wrote: >> >> [snip] > > diff --git a/common/rc

Re: [PATCH v2] fstests: btrfs: fix 006 adds _runnt_btrfs_util_prog()

On 06/23/2016 07:18 PM, Eryu Guan wrote: On Thu, Jun 23, 2016 at 07:03:59PM +0800, Anand Jain wrote: On 06/23/2016 06:53 PM, Eryu Guan wrote: [snip] diff --git a/common/rc b/common/rc index a44fb8750220..2a10fbb2d341 100644 --- a/common/rc +++ b/common/rc @@ -3114,6 +3114,17 @@

Re: [PATCH v2] fstests: btrfs: fix 006 adds _runnt_btrfs_util_prog()

On Thu, Jun 23, 2016 at 07:03:59PM +0800, Anand Jain wrote: > > > On 06/23/2016 06:53 PM, Eryu Guan wrote: [snip] > > > diff --git a/common/rc b/common/rc > > > index a44fb8750220..2a10fbb2d341 100644 > > > --- a/common/rc > > > +++ b/common/rc > > > @@ -3114,6 +3114,17 @@ _min_dio_alignment() >

Re: [PATCH v2] fstests: btrfs: fix 006 adds _runnt_btrfs_util_prog()

On 06/23/2016 06:53 PM, Eryu Guan wrote: On Thu, Jun 23, 2016 at 06:37:32PM +0800, Anand Jain wrote: btrfs fi sync /mnt, now does not output anything for success, so the 006.out should be updated. This change in btrfs-progs was introduced in the commit

[PULL] Btrfs updates for 4.7-rc5

Hi, this is hopefully the last pull for 4.7 from me. There are two fixes that should finalize the changes introduced in this dev cycle, plus some minor independent fixes. The following changes since commit 33688abb2802ff3a230bd2441f765477b94cc89e: Linux 4.7-rc4 (2016-06-19 21:30:02 -0700)

Re: [PATCH v2] fstests: btrfs: fix 006 adds _runnt_btrfs_util_prog()

On Thu, Jun 23, 2016 at 06:37:32PM +0800, Anand Jain wrote: > btrfs fi sync /mnt, now does not output anything for success, > so the 006.out should be updated. > > This change in btrfs-progs was introduced in the commit > b005ca024990569d2de459485682158633937928 >btrfs-progs: fi sync: make

[PATCH v2] fstests: btrfs: fix 006 adds _runnt_btrfs_util_prog()

btrfs fi sync /mnt, now does not output anything for success, so the 006.out should be updated. This change in btrfs-progs was introduced in the commit b005ca024990569d2de459485682158633937928 btrfs-progs: fi sync: make it silent by default which was integrated at btrfs-progs version v4.5.2

Re: [PATCH] fstests: btrfs: fix 006 adds _runnt_btrfs_util_prog()

On 06/23/2016 06:17 PM, Eryu Guan wrote: On Thu, Jun 23, 2016 at 06:01:36PM +0800, Anand Jain wrote: btrfs fi sync /mnt, now does not output anything for success, so the 006.out should be updated. btrfs-progs v4.4 still outputs "FSSync ''", it'd be good to state starting from which version

Re: [PATCH] fstests: btrfs: fix 006 adds _runnt_btrfs_util_prog()

On Thu, Jun 23, 2016 at 06:01:36PM +0800, Anand Jain wrote: > btrfs fi sync /mnt, now does not output anything for success, > so the 006.out should be updated. btrfs-progs v4.4 still outputs "FSSync ''", it'd be good to state starting from which version or commit the behavior changes. > >

Re: [PATCH] Btrfs: Force stripesize to the value of sectorsize

On Thu, Jun 23, 2016 at 03:16:44PM +0530, Chandan Rajendra wrote: > Btrfs code currently assumes stripesize to be same as > sectorsize. However Btrfs-progs (until commit > df05c7ed455f519e6e15e46196392e4757257305) has been setting > btrfs_super_block->stripesize to a value of 4096. > > This

Re: On shrinkable caches

On 06/23/2016 12:43 PM, David Sterba wrote: > On Mon, Jun 20, 2016 at 02:26:12PM +0300, Nikolay Borisov wrote: >> I have a question regarding the SLAB_RECLAIM_ACCOUNT flag with which >> BTRFS caches are created. Currently there isn't a single usage of >> register_shrinker under fs/btrfs. > >

[PATCH] fstests: btrfs: fix 006 adds _runnt_btrfs_util_prog()

btrfs fi sync /mnt, now does not output anything for success, so the 006.out should be updated. Further created helper function _runnt_btrfs_utils_progs() which won't call _fail upon command failure, instead it just echo to stdout. This was required so to continue with the test script and do the

[PATCH] Btrfs: Force stripesize to the value of sectorsize

Btrfs code currently assumes stripesize to be same as sectorsize. However Btrfs-progs (until commit df05c7ed455f519e6e15e46196392e4757257305) has been setting btrfs_super_block->stripesize to a value of 4096. This commit makes sure that the value of btrfs_super_block->stripesize is a power of 2.

Re: On shrinkable caches

On Mon, Jun 20, 2016 at 02:26:12PM +0300, Nikolay Borisov wrote: > I have a question regarding the SLAB_RECLAIM_ACCOUNT flag with which > BTRFS caches are created. Currently there isn't a single usage of > register_shrinker under fs/btrfs. The SLAB_RECLAIM_ACCOUNT flag has been there since the

Re: [RFC PATCH] btrfs: fix free space calculation in dump_space_info()

On Tue, Jun 21, 2016 at 09:47:13AM +0800, Wang Xiaoguang wrote: > hello, > > On 06/21/2016 02:09 AM, Omar Sandoval wrote: > > On Mon, Jun 20, 2016 at 06:47:05PM +0800, Wang Xiaoguang wrote: > >> Signed-off-by: Wang Xiaoguang > >> --- > >> fs/btrfs/extent-tree.c | 4

Re: [PATCH] btrfs: check truncate can update file size correctly when truncate fails

On Thu, Jun 23, 2016 at 03:36:40PM +0800, Wang Xiaoguang wrote: > In btrfs, when truncate operation fails for enospc reason, file may still > have some disk blocks, but it will fail to update filesize accordingly. Any reason this isn't a generic test? Seems nothing in the test case really is

Re: [PATCH] Btrfs: fix BUG_ON in btrfs_submit_compressed_write

On Wed, Jun 22, 2016 at 06:32:06PM -0700, Liu Bo wrote: > This is similar to btrfs_submit_compressed_read(), if we fail after > bio is allocated, then we can use bio_endio() and errors are saved > in bio->bi_error. But please note that we don't return errors to > its caller because the caller

Re: [PATCH] Btrfs: error out if generic_bin_search get invalid arguments

On Wed, Jun 22, 2016 at 06:32:19PM -0700, Liu Bo wrote: > With btrfs-corrupt-block, one can set btree node/leaf's field, if > we assign a negative value to node/leaf, we can get various hangs, > eg. if extent_root's nritems is -2ULL, then we get stuck in > btrfs_read_block_groups() because it has

Re: [PATCH] btrfs: check truncate can update file size correctly when truncate fails

On Thu, Jun 23, 2016 at 03:36:40PM +0800, Wang Xiaoguang wrote: > In btrfs, when truncate operation fails for enospc reason, file may still > have some disk blocks, but it will fail to update filesize accordingly. > > Signed-off-by: Wang Xiaoguang > --- >

Re: btrfs send/receive error

Michael Duell rub.de> writes: > > Hallo Lubos! > > I have got the same problems with send/receive. Had those problems > for several weeks or months now. Not sure when those started. > > These send/receive problems are known and there are several bug > reports all over the internet and also

[PATCH] btrfs: check truncate can update file size correctly when truncate fails

In btrfs, when truncate operation fails for enospc reason, file may still have some disk blocks, but it will fail to update filesize accordingly. Signed-off-by: Wang Xiaoguang --- tests/btrfs/124 | 86 +