> 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 indivi
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.
---
fs/btrfs/disk-io.c | 9 -
1 file
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 b/fs/btrfs/disk-io.c
inde
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 also
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 (f
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
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
>
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, t
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, BTR
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
>>> btrbk FAQ entry s
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 t
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: send the line "unsubscribe linux-btrfs" in
th
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 ins
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
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>
>
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 alr
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
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.
>
>
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 7d5a9b5..efa4c23 100644
> --- a/fs/b
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 mailing lists for
all
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 to
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 pro
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 set, done by
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 addres
> 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.
>
I'l
>
> 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;
> }
> }
> re
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 addres
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 su
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 fine
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 somethi
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
> b/drivers/net/ethernet/sun/cassini.c
> index 382993c..
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. That is only called by b
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 an
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. Overall
> performance gain on HDD and SSD were
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 btrfs send, we found it
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
> performance gain on HD
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
+++ b/drivers/gpu/drm/gm
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
--- a/arch/powerpc/platforms/cell/spide
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
+++ b/drivers/net/bonding/bond_alb.c
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
+++ b/drivers/crypto/omap-aes-gcm.c
@@ -1
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
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/me
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
--- a/drivers/scsi/megaraid/megaraid_mbox.c
+++
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
--- a/drivers/net/ethernet/sun/cassini.c
+++ b/drivers/net/et
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
--- a/drivers/target/iscsi/cxgbit/
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
--- a/drivers/video/fbdev/matrox/matr
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
+++ b/fs/btrfs/check-integrity.c
@@ -2913,7 +2913,7 @
46 matches
Mail list logo