Re: [PATCH 01/10] arch:powerpc: return -ENOMEM on failed allocation

> I think the changelog for this series of conversions > should show that you've validated the change by > inspecting the return call chain at each modified line. > > Also, it seems you've cc'd the same mailing lists for > all of the patches modified by this series. > > It would be better to

Re: [PATCH] Btrfs: do not backup tree roots when fsync

On 2017年09月14日 02:25, Liu Bo wrote: It doens't make sense to backup tree roots when doing fsync, since during fsync those tree roots have not been consistent on disk. Signed-off-by: Liu Bo Reviewed-by: Qu Wenruo With a pit can be improved.

[PATCH] Btrfs: do not backup tree roots when fsync

It doens't make sense to backup tree roots when doing fsync, since during fsync those tree roots have not been consistent on disk. Signed-off-by: Liu Bo --- fs/btrfs/disk-io.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/disk-io.c

[PATCH 2/2 v2] Btrfs: remove bio_flags which indicates a meta block of log-tree

Since both committing transaction and writing log-tree are doing plugging on metadata IO, we can unify to use %sync_writers to benefit both cases, instead of checking bio_flags while writing meta blocks of log-tree. We can remove this bio_flags because in order to write dirty blocks, log tree

[PATCH] Btrfs: fix confusing worker helper info

We've seen the following backtrace stack in ftrace or dmesg log, kworker/u16:10-4244 [000] 241942.480955: function: btrfs_put_ordered_extent kworker/u16:10-4244 [000] 241942.480956: kernel_stack: => finish_ordered_fn (a0384475) => btrfs_scrubparity_helper

Re: [PATCH 2/2] Btrfs: remove bio_flags which indicates a meta block of log-tree

On Wed, Sep 13, 2017 at 06:43:30PM +0200, David Sterba wrote: > On Mon, Aug 21, 2017 at 03:50:00PM -0600, Liu Bo wrote: > > Since both committing transaction and writing log-tree are doing > > plugging on metadata IO, we can unify to use %sync_writers to benefit > > both cases, instead of checking

Re: qemu-kvm VM died during partial raid1 problems of btrfs

On 09/13/2017 04:15 PM, Marat Khalili wrote: > On 13/09/17 16:23, Chris Murphy wrote: >> Right, known problem. To use o_direct implies also using nodatacow (or >> at least nodatasum), e.g. xattr +C is set, done by qemu-img -o >> nocow=on >> https://www.spinics.net/lists/linux-btrfs/msg68244.html >

Re: [PATCH 1/2 RESEND] Btrfs: make plug in writing meta blocks really work

On Wed, Sep 13, 2017 at 05:51:55PM +0200, David Sterba wrote: > On Mon, Aug 21, 2017 at 03:49:59PM -0600, Liu Bo wrote: > > We have started plug in btrfs_write_and_wait_marked_extents() but the > > generated IOs actually go to device's schedule IO list where the work > > is doing in another task,

Re: [PATCH] btrfs: remove BTRFS_FS_QUOTA_DISABLING flag

On Wed, Aug 30, 2017 at 04:33:16PM +0900, Misono, Tomohiro wrote: > Currently, "btrfs quota enable" would fail after "btrfs quota disable" on > the first time with syslog output "qgroup_rescan_init failed with -22", but > it would succeed on the second time. > > When "quota disable" is called,

Re: send | receive: received snapshot is missing recent files

On Mon, Sep 11, 2017 at 11:19 PM, Andrei Borzenkov wrote: > 11.09.2017 20:53, Axel Burri пишет: >> On 2017-09-08 06:44, Dave wrote: >>> I'm referring to the link below. Using "btrfs subvolume snapshot -r" >>> copies the Received UUID from the source into the new snapshot. The

Re: [PATCH 2/2] Btrfs: remove bio_flags which indicates a meta block of log-tree

On Mon, Aug 21, 2017 at 03:50:00PM -0600, Liu Bo wrote: > Since both committing transaction and writing log-tree are doing > plugging on metadata IO, we can unify to use %sync_writers to benefit > both cases, instead of checking bio_flags while writing meta blocks of > log-tree. > > This removes

Re: [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.

From: Allen Pais Date: Wed, 13 Sep 2017 13:02:15 +0530 > Signed-off-by: Allen Pais This is quite pointless as the caller doesn't do anything with the value, it just tests whether a negative value is returned or not. -- To unsubscribe from this list:

Btrfs Issues

Hello, We are researchers from Columbia University, New York. As part of our current research we have found some semantic discrepancies between btrfs and other popular filesystems. We have attached two cases. The first one involves an invalid O_DIRECT write() that fails back to buffered write

Re: [PATCH 1/2 RESEND] Btrfs: make plug in writing meta blocks really work

On Mon, Aug 21, 2017 at 03:49:59PM -0600, Liu Bo wrote: > We have started plug in btrfs_write_and_wait_marked_extents() but the > generated IOs actually go to device's schedule IO list where the work > is doing in another task, thus the started plug doesn't make any > sense. > > And since we wait

Re: [PATCH RFC] Btrfs: fix confusing worker helper info

On Fri, Sep 08, 2017 at 03:34:45PM -0600, Liu Bo wrote: > We've seen the following backtrace stack in ftrace or dmesg log, > > kworker/u16:10-4244 [000] 241942.480955: function: > btrfs_put_ordered_extent > kworker/u16:10-4244 [000] 241942.480956: kernel_stack: trace>

Re: [PATCH] btrfs: propagate error to btrfs_cmp_data_prepare caller

On Fri, Sep 08, 2017 at 05:48:55PM +0900, Naohiro Aota wrote: > btrfs_cmp_data_prepare() (almost) always returns 0 i.e. ignoring errors > from gather_extent_pages(). While the pages are freed by > btrfs_cmp_data_free(), cmp->num_pages still has > 0. Then, > btrfs_extent_same() try to access the

Re: qemu-kvm VM died during partial raid1 problems of btrfs

On 2017-09-13 10:47, Martin Raiber wrote: Hi, On 12.09.2017 23:13 Adam Borowski wrote: On Tue, Sep 12, 2017 at 04:12:32PM -0400, Austin S. Hemmelgarn wrote: On 2017-09-12 16:00, Adam Borowski wrote: Noted. Both Marat's and my use cases, though, involve VMs that are off most of the time, and

Re: [PATCH] btrfs: prevent to set invalid default subvolid

On Tue, Sep 12, 2017 at 10:42:52PM +0900, Satoru Takeuchi wrote: > `btrfs sub set-default` succeeds to set an ID which isn't corresponding to any > fs/file tree. If such the bad ID is set to a filesystem, we can't mount this > filesystem without specifying `subvol` or `subvolid` mount options. >

Re: [PATCH 10/10] fs:btrfs: return -ENOMEM on allocation failure.

On Wed, Sep 13, 2017 at 01:02:19PM +0530, Allen Pais wrote: > Signed-off-by: Allen Pais > --- > fs/btrfs/check-integrity.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c > index

Re: [PATCH 01/10] arch:powerpc: return -ENOMEM on failed allocation

On Wed, 2017-09-13 at 13:02 +0530, Allen Pais wrote: > Signed-off-by: Allen Pais I think the changelog for this series of conversions should show that you've validated the change by inspecting the return call chain at each modified line. Also, it seems you've cc'd the same

Re: qemu-kvm VM died during partial raid1 problems of btrfs

Hi, On 12.09.2017 23:13 Adam Borowski wrote: > On Tue, Sep 12, 2017 at 04:12:32PM -0400, Austin S. Hemmelgarn wrote: >> On 2017-09-12 16:00, Adam Borowski wrote: >>> Noted. Both Marat's and my use cases, though, involve VMs that are off most >>> of the time, and at least for me, turned on only

Re: qemu-kvm VM died during partial raid1 problems of btrfs

On 13/09/17 16:23, Chris Murphy wrote: Right, known problem. To use o_direct implies also using nodatacow (or at least nodatasum), e.g. xattr +C is set, done by qemu-img -o nocow=on https://www.spinics.net/lists/linux-btrfs/msg68244.html Can you please elaborate? I don't have exactly the same

Re: qemu-kvm VM died during partial raid1 problems of btrfs

On Tue, Sep 12, 2017 at 10:02 AM, Marat Khalili wrote: > (3) it is possible that it uses O_DIRECT or something, and btrfs raid1 does > not fully protect this kind of access. Right, known problem. To use o_direct implies also using nodatacow (or at least nodatasum), e.g. xattr +C is

discard and rollback

Hi, I've been running discard mount option continuously for about 9 months with an HP Spectre which contains a SAMSUNG MZVLV256HCHP-000H1 as reported by smartctl. There have been no problems. However I realize today that within seconds of a super being updated with a new root tree, the old

Re: [PATCH 05/10] drivers:net: return -ENOMEM on allocation failure.

> propagates the -1. That is only called by bond_open() with: > > if (bond_alb_initialize(bond, (BOND_MODE(bond) == BOND_MODE_ALB))) > return -ENOMEM; > > So you might want to also modify this code, to return the return > value, rather than use the hard coded ENOMEM. >

Re: [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.

> > static int cas_alloc_rxds(struct cas *cp) > { > int i; > > for (i = 0; i < N_RX_DESC_RINGS; i++) { > if (cas_alloc_rx_desc(cp, i) < 0) { > cas_free_rxds(cp); > return -1; > } > } >

discard and rollback

Hi, I've been running discard mount option continuously for about 9 months with an HP Spectre which contains a SAMSUNG MZVLV256HCHP-000H1 as reported by smartctl. There have been no problems. However I realize today that within seconds of a super being updated with a new root tree, the old

Re: qemu-kvm VM died during partial raid1 problems of btrfs

On 2017-09-12 20:52, Timofey Titovets wrote: No, no, no, no... No new ioctl, no change in fallocate. Fisrt: VM can do punch hole, if you use qemu -> qemu know how to do it. Windows Guest also know how to do it. Different Hypervisor? -> google -> Make issue to support, all Linux/Windows/Mac OS

Re: Storage and snapshots as historical yearly

On 2017-09-13 07:51, Pete wrote: On 09/12/2017 01:16 PM, Austin S. Hemmelgarn wrote: Diverting away from the original topic, what issues with overlayfs and btrfs? As mentioned, I thought whiteout support was missing, but if you're using it without issue, I might be wrong. Whiteout works

Re: qemu-kvm VM died during partial raid1 problems of btrfs

On 2017-09-12 17:13, Adam Borowski wrote: On Tue, Sep 12, 2017 at 04:12:32PM -0400, Austin S. Hemmelgarn wrote: On 2017-09-12 16:00, Adam Borowski wrote: Noted. Both Marat's and my use cases, though, involve VMs that are off most of the time, and at least for me, turned on only to test

Re: [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.

On Wed, Sep 13, 2017 at 01:02:15PM +0530, Allen Pais wrote: > Signed-off-by: Allen Pais > --- > drivers/net/ethernet/sun/cassini.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/sun/cassini.c >

Re: [PATCH 05/10] drivers:net: return -ENOMEM on allocation failure.

On Wed, Sep 13, 2017 at 01:02:14PM +0530, Allen Pais wrote: > Signed-off-by: Allen Pais Hi Allen Although correct, if you look higher up the call chain, this appears to be not so useful. rlb_initialize() is only called by bond_alb_initialize(), and it propagates the -1.

Re: Storage and snapshots as historical yearly

On 09/12/2017 01:16 PM, Austin S. Hemmelgarn wrote: >> Diverting away from the original topic, what issues with overlayfs and >> btrfs? > As mentioned, I thought whiteout support was missing, but if you're > using it without issue, I might be wrong. Whiteout works fine. Upper and lower layers

Re: [PATCH] Btrfs: incremental send, apply asynchronous page cache readahead

On Wed, Sep 13, 2017 at 7:38 AM, peterh wrote: > From: Kuanling Huang > > By analyzing the perf on btrfs send, we found it take large > amount of cpu time on page_cache_sync_readahead. This effort > can be reduced after switching to asynchronous one.

Re: [PATCH] Btrfs: incremental send, apply asynchronous page cache readahead

Hi Pasi Sorry for missing the word. 9 and 15 percent performance gain on HDD and SSD after the patch is applied. Kuanling Pasi Kärkkäinen 於 2017-09-13 17:33 寫到: Hi, On Wed, Sep 13, 2017 at 02:38:49PM +0800, peterh wrote: From: Kuanling Huang By analyzing the perf on

Re: [PATCH] Btrfs: incremental send, apply asynchronous page cache readahead

Hi, On Wed, Sep 13, 2017 at 02:38:49PM +0800, peterh wrote: > From: Kuanling Huang > > By analyzing the perf on btrfs send, we found it take large > amount of cpu time on page_cache_sync_readahead. This effort > can be reduced after switching to asynchronous one. Overall >

[PATCH 03/10] driver:gpu: return -ENOMEM on allocation failure.

Signed-off-by: Allen Pais --- drivers/gpu/drm/gma500/mid_bios.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/gma500/mid_bios.c b/drivers/gpu/drm/gma500/mid_bios.c index d75ecb3..1fa1633 100644 --- a/drivers/gpu/drm/gma500/mid_bios.c

[PATCH 01/10] arch:powerpc: return -ENOMEM on failed allocation

Signed-off-by: Allen Pais --- arch/powerpc/platforms/cell/spider-pci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/cell/spider-pci.c b/arch/powerpc/platforms/cell/spider-pci.c index d1e61e2..82aa3f7 100644 ---

[PATCH 05/10] drivers:net: return -ENOMEM on allocation failure.

Signed-off-by: Allen Pais --- drivers/net/bonding/bond_alb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c index c02cc81..89df377 100644 --- a/drivers/net/bonding/bond_alb.c +++

[PATCH 02/10] drivers:crypto: return -ENOMEM on allocation failure.

Signed-off-by: Allen Pais --- drivers/crypto/omap-aes-gcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/omap-aes-gcm.c b/drivers/crypto/omap-aes-gcm.c index 7d4f8a4..2542224 100644 --- a/drivers/crypto/omap-aes-gcm.c +++

[PATCH 04/10] drivers:mpt: return -ENOMEM on allocation failure.

Signed-off-by: Allen Pais --- drivers/message/fusion/mptbase.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c index 84eab28..7920b2b 100644 ---

[PATCH 07/10] driver:megaraid: return -ENOMEM on allocation failure.

Signed-off-by: Allen Pais --- drivers/scsi/megaraid/megaraid_mbox.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_mbox.c b/drivers/scsi/megaraid/megaraid_mbox.c index ec3c438..b09a0a6 100644 ---

[PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.

Signed-off-by: Allen Pais --- drivers/net/ethernet/sun/cassini.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/sun/cassini.c b/drivers/net/ethernet/sun/cassini.c index 382993c..fc0ea3a 100644 ---

[PATCH 08/10] driver:cxgbit: return -NOMEM on allocation failure.

Signed-off-by: Allen Pais --- drivers/target/iscsi/cxgbit/cxgbit_target.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/target/iscsi/cxgbit/cxgbit_target.c b/drivers/target/iscsi/cxgbit/cxgbit_target.c index 514986b..47127d6 100644 ---

[PATCH 09/10] driver:video: return -ENOMEM on allocation failure.

Signed-off-by: Allen Pais --- drivers/video/fbdev/matrox/matroxfb_base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c b/drivers/video/fbdev/matrox/matroxfb_base.c index f6a0b9a..5cd238d 100644 ---

[PATCH 10/10] fs:btrfs: return -ENOMEM on allocation failure.

Signed-off-by: Allen Pais --- fs/btrfs/check-integrity.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c index 7d5a9b5..efa4c23 100644 --- a/fs/btrfs/check-integrity.c +++

[PATCH] Btrfs: incremental send, apply asynchronous page cache readahead

From: Kuanling Huang By analyzing the perf on btrfs send, we found it take large amount of cpu time on page_cache_sync_readahead. This effort can be reduced after switching to asynchronous one. Overall performance gain on HDD and SSD were 9 and 15 respectively if simply send