Re: [PATCH v2] Fstest: btrfs/151: test if device delete ends up with losing raid profile

On Fri, Oct 13, 2017 at 01:40:05PM -0600, Liu Bo wrote: > Currently running 'btrfs device delete' can end up with losing data > raid profile (if any), this test is to reproduce the problem. > > The fix is > "Btrfs: avoid losing data raid profile when deleting a device" > > Signed-off-by:

[PATCH] btrfs: use BLK_STS defines where needed

At few places we could use BLK_STS_OK and BLK_STS_NOSUPP. Signed-off-by: Anand Jain --- fs/btrfs/compression.c | 3 ++- fs/btrfs/inode.c | 4 ++-- fs/btrfs/volumes.c | 2 +- 3 files changed, 5 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/compression.c

Re: [PATCH] btrfs: fix false EIO for missing device

- bio->bi_status = BLK_STS_IOERR; + if (atomic_read(>error) > bbio->max_errors) + bio->bi_status = BLK_STS_IOERR; + else + bio->bi_status = 0; Thanks for the fix, I'd prefer BLK_STS_OK rather than 0. With

[PATCH v2] btrfs: fix false EIO for missing device

When one of the device is missing, bbio_error() takes care of setting the error status. And if its only IO that is pending in that stripe, it fails to check the status of the other IO at %bbio_error before setting the error %bi_status for the %orig_bio. Fix this by checking if %bbio->error is has

Re: [PATCH 2/4] Btrfs: clear_dirty only on pages only in compression range

2017-10-10 19:22 GMT+03:00 David Sterba : > On Tue, Oct 03, 2017 at 06:06:02PM +0300, Timofey Titovets wrote: >> We need to call extent_range_clear_dirty_for_io() >> on compression range to prevent application from changing >> page content, while pages compressing. >> >> but "(end

[PATCH] Btrfs: add write_flags for compression bio

Compression code path has only flaged bios with REQ_OP_WRITE no matter where the bios come from. This breaks the rule that sync writes and writeback writes need to be differentiated from each other. This passes writeback_control to compression write path so that it can send bios with proper

Re: Btrfs warnings in kernel 4.13.5

2017-10-13 20:15 GMT+02:00 Chris Murphy : > On Fri, Oct 13, 2017 at 12:02 PM, Duncan <1i5t5.dun...@cox.net> wrote: >> Those warnings aren't anything to be /too/ worried about. They are >> triggered when a btrfs device size isn't a multiple of the btrfs >> sectorsize

Re: [PATCH v2] Btrfs: avoid losing data raid profile when deleting a device

On Wed, Oct 11, 2017 at 10:38:50AM +0300, Nikolay Borisov wrote: > > > On 10.10.2017 20:53, Liu Bo wrote: > > We've avoided data losing raid profile when doing balance, but it > > turns out that deleting a device could also result in the same > > problem > > > > This fixes the problem by

[PATCH v2] Fstest: btrfs/151: test if device delete ends up with losing raid profile

Currently running 'btrfs device delete' can end up with losing data raid profile (if any), this test is to reproduce the problem. The fix is "Btrfs: avoid losing data raid profile when deleting a device" Signed-off-by: Liu Bo --- tests/btrfs/151 | 73

Re: [PATCH v8 1/2] btrfs: introduce device dynamic state transition to failed

On Tue, Oct 03, 2017 at 11:59:19PM +0800, Anand Jain wrote: > From: Anand Jain > > This patch provides helper functions to force a device to failed, > and we need it for the following reasons, > 1) a. It can be reported that device has failed when it does and >b. Close

Re: [PATCH v8 2/2] btrfs: check device for critical errors and mark failed

On Sun, Oct 08, 2017 at 10:23:58PM +0800, Anand Jain wrote: > > > On 10/07/2017 07:56 AM, Liu Bo wrote: > > On Thu, Oct 05, 2017 at 09:56:59PM +0800, Anand Jain wrote: > > > > > > > > > On 10/05/2017 04:11 AM, Liu Bo wrote: > > > > On Tue, Oct 03, 2017 at 11:59:20PM +0800, Anand Jain wrote: >

Re: USB upgrade fun

On Fri, Oct 13, 2017 at 12:22 PM, Austin S. Hemmelgarn wrote: > From a practical perspective, you're almost certainly better off creating a > copy for cold storage without involving BTRFS. Yeah if you want to hedge your bets, and keep it simple, rsync to XFS. With some

Re: Btrfs warnings in kernel 4.13.5

On Fri, Oct 13, 2017 at 12:02 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Juan Orti Alcaine posted on Fri, 13 Oct 2017 10:40:20 +0200 as excerpted: > >> Hi, >> >> I've upgraded my system to Fedora 27 and now I see many btrfs warnings, >> although the system seems to be working fine. Is this

Re: [PATCH] Fstest: btrfs/151: test if device delete ends up with losing raid profile

On Thu, Oct 12, 2017 at 03:06:57PM +0800, Eryu Guan wrote: > On Mon, Oct 09, 2017 at 11:39:21AM -0600, Liu Bo wrote: > > Currently running 'btrfs device delete' can end up with losing data raid > > profile (if any), this test is to reproduce the problem. > > > > The fix is > > "Btrfs: avoid

Re: [PATCH] btrfs: fix false EIO for missing device

On Fri, Oct 13, 2017 at 09:42:18PM +0800, Anand Jain wrote: > When one of the device is missing, bbio_error() takes care > of setting the error status. And if its only IO that is > pending in that stripe, it fails to check the status of the > other IO at %bbio_error before setting the error

Re: btrfs errors over NFS

>> TL;DR: ran into some btrfs errors and weird behaviour, but >> things generally seem to work. Just posting some details in >> case it helps devs or other users. [ ... ] I've run into a >> btrfs error trying to do a -j8 build of android on a btrfs >> filesystem exported over NFSv3. [ ... ] I

Re: [PATCH 14/21] btrfs: remove type argument from comp_tree_refs

On Fri, Sep 29, 2017 at 03:43:58PM -0400, Josef Bacik wrote: > We can get this from the ref we've passed in. > > Signed-off-by: Josef Bacik Reviewed-by: David Sterba -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a

Re: [PATCH 13/21] btrfs: remove delayed_ref_node from ref_head

On Fri, Sep 29, 2017 at 03:43:57PM -0400, Josef Bacik wrote: > This is just excessive information in the ref_head, and makes the code > complicated. It is a relic from when we had the heads and the refs in > the same tree, which is no longer the case. With this removal I've > cleaned up a bunch

Re: [PATCH 12/21] btrfs: move all ref head cleanup to the helper function

On Fri, Sep 29, 2017 at 03:43:56PM -0400, Josef Bacik wrote: > We do a couple different cleanup operations on the ref head. We adjust > counters, we'll free any reserved space if we didn't end up using the > ref, and we clear the pending csum bytes. Move all these disparate > things into

Re: [PATCH 11/21] btrfs: move ref_mod modification into the if (ref) logic

On Fri, Sep 29, 2017 at 03:43:55PM -0400, Josef Bacik wrote: > We only use this logic if our ref isn't a ref_head, so move it up into > the if (ref) case since we know that this is a normal ref and not a > delayed ref head. > > Signed-off-by: Josef Bacik Reviewed-by: David Sterba

Re: [PATCH 10/21] btrfs: breakout empty head cleanup to a helper

On Fri, Sep 29, 2017 at 03:43:54PM -0400, Josef Bacik wrote: > Move this code out to a helper function to further simplivy > __btrfs_run_delayed_refs. > > Signed-off-by: Josef Bacik Reviewed-by: David Sterba -- To unsubscribe from this list: send the line

Re: [PATCH 09/21] btrfs: move extent_op cleanup to a helper

On Fri, Sep 29, 2017 at 03:43:53PM -0400, Josef Bacik wrote: > Move the extent_op cleanup for an empty head ref to a helper function to > help simplify __btrfs_run_delayed_refs. > > Signed-off-by: Josef Bacik Reviewed-by: David Sterba -- To unsubscribe from

Re: [PATCH 08/21] btrfs: add a helper to return a head ref

On Fri, Sep 29, 2017 at 03:43:52PM -0400, Josef Bacik wrote: > Simplify the error handling in __btrfs_run_delayed_refs by breaking out > the code used to return a head back to the delayed_refs tree for > processing into a helper function. > > Signed-off-by: Josef Bacik

Re: [PATCH 06/21] Btrfs: add a extent ref verify tool

On Fri, Sep 29, 2017 at 03:43:50PM -0400, Josef Bacik wrote: > We were having corruption issues that were tied back to problems with the > extent > tree. In order to track them down I built this tool to try and find the > culprit, which was pretty successful. If you compile with this tool on it

Re: [PATCH 05/21] btrfs: pass root to various extent ref mod functions

On Fri, Sep 29, 2017 at 03:43:49PM -0400, Josef Bacik wrote: > We need the actual root for the ref verifier tool to work, so change > these functions to pass the root around instead. This will be used in > a subsequent patch. > > Signed-off-by: Josef Bacik Reviewed-by: David

Re: [PATCH 04/21] btrfs: add ref-verify mount option

On Fri, Oct 13, 2017 at 03:53:36PM +0200, David Sterba wrote: > On Fri, Sep 29, 2017 at 03:43:48PM -0400, Josef Bacik wrote: > > This adds the infrastructure for turning ref verify on and off for a > > mount, to be used by a later patch. > > > > Signed-off-by: Josef Bacik > >

Re: [PATCH 01/21] Btrfs: rework outstanding_extents

> > The outstanding_extents accounting is consistent with only the items needed to > handle the outstanding extent items. However since changing the inode > requires > updating the inode item as well we have to keep this floating reservation for > the inode item until we have 0 outstanding

Re: [PATCH 04/21] btrfs: add ref-verify mount option

On Fri, Sep 29, 2017 at 03:43:48PM -0400, Josef Bacik wrote: > This adds the infrastructure for turning ref verify on and off for a > mount, to be used by a later patch. > > Signed-off-by: Josef Bacik Reviewed-by: David Sterba -- To unsubscribe from this list:

[PATCH] btrfs: fix false EIO for missing device

When one of the device is missing, bbio_error() takes care of setting the error status. And if its only IO that is pending in that stripe, it fails to check the status of the other IO at %bbio_error before setting the error %bi_status for the %orig_bio. Fix this by checking if %bbio->error is has

Re: [PATCH 01/21] Btrfs: rework outstanding_extents

On Fri, Oct 13, 2017 at 09:10:52AM -0400, Josef Bacik wrote: > On Fri, Oct 13, 2017 at 11:39:15AM +0300, Nikolay Borisov wrote: > > > > > > On 29.09.2017 22:43, Josef Bacik wrote: > > > > > > +static inline void btrfs_mod_outstanding_extents(struct btrfs_inode > > > *inode, > > > +

Re: [PATCH] btrfs: cleanup extent locking sequence

On Tue, Oct 10, 2017 at 09:26:41PM -0500, Goldwyn Rodrigues wrote: > From: Goldwyn Rodrigues > > Code cleanup for better understanding: > needs_unlock to be called extent_locked to show state as opposed to > action. > Changed the variable to int, to reduce code in the critical

Re: [PATCH 03/21] btrfs: make the delalloc block rsv per inode

On Fri, Oct 13, 2017 at 02:47:32PM +0300, Nikolay Borisov wrote: > > > > @@ -8848,7 +8849,6 @@ static ssize_t btrfs_direct_IO(struct kiocb *iocb, > > struct iov_iter *iter) > > if (iov_iter_rw(iter) == WRITE) { > > up_read(_I(inode)->dio_sem); > >

Re: [PATCH 01/21] Btrfs: rework outstanding_extents

On Fri, Oct 13, 2017 at 11:39:15AM +0300, Nikolay Borisov wrote: > > > On 29.09.2017 22:43, Josef Bacik wrote: > > > > +static inline void btrfs_mod_outstanding_extents(struct btrfs_inode *inode, > > +int mod) > > +{ > > +

Re: [PATCH][v2] btrfs: fix send ioctl on 32bit with 64bit kernel

On Wed, Sep 27, 2017 at 10:43:13AM -0400, Josef Bacik wrote: > We pass in a pointer in our send arg struct, this means the struct size > doesn't > match with 32bit user space and 64bit kernel space. Fix this by adding a > compat > mode and doing the appropriate conversion. > > Signed-off-by:

Re: [PATCH v2 1/4] btrfs: add_missing_dev() should return the actual error

On Mon, Oct 09, 2017 at 11:07:43AM +0800, Anand Jain wrote: > add_missing_dev() can return device pointer so that IS_ERR/ > PTR_ERR can be used to check for the actual error occurred > in the function. > > Signed-off-by: Anand Jain > --- 1-4 added, with some tweaks.

Re: [PATCH v2 2/4] btrfs: fix EIO misuse to report missing degraded option

On Mon, Oct 09, 2017 at 11:07:44AM +0800, Anand Jain wrote: > EIO is only for the IO failure to the device, avoid it. > > Signed-off-by: Anand Jain Updated changelog. Reviewed-by: David Sterba -- To unsubscribe from this list: send the line

Re: [PATCH v3 1/4] btrfs: add_missing_dev() should return the actual error

On Wed, Oct 11, 2017 at 12:46:18PM +0800, Anand Jain wrote: > add_missing_dev() can return device pointer so that IS_ERR/ > PTR_ERR can be used to check for the actual error occurred > in the function. > > Signed-off-by: Anand Jain > Reviewed-by: Liu Bo

Re: [PATCH] btrfs: Clean up unused variables in free-space-tree.c

On Thu, Oct 12, 2017 at 02:43:27PM -0700, Omar Sandoval wrote: > On Thu, Oct 12, 2017 at 10:40:42PM +0100, Christos Gkekas wrote: > > Remove variables 'start' and 'end', which are set but never used. > > Oops. > > Reviewed-by: Omar Sandoval Thanks, added to the queue. -- To

Re: [PATCH] btrfs: tree-checker: use %zu format string for size_t

On Fri, Oct 13, 2017 at 11:27:35AM +0200, Arnd Bergmann wrote: > We now get a harmless compile-time on 32-bit architectures: > > fs/btrfs/tree-checker.c: In function 'check_extent_data_item': > fs/btrfs/tree-checker.c:189:70: error: format '%lu' expects argument of type > 'long unsigned int',

Re: Btrfs warnings in kernel 4.13.5

2017-10-13 13:02 GMT+02:00 Duncan <1i5t5.dun...@cox.net>: > Those warnings aren't anything to be /too/ worried about. They are > triggered when a btrfs device size isn't a multiple of the btrfs > sectorsize (currently 4 KiB on amd64 aka x86_64). You can manually > shrink your btrfs devices the

Re: [PATCH 03/21] btrfs: make the delalloc block rsv per inode

On 29.09.2017 22:43, Josef Bacik wrote: > The way we handle delalloc metadata reservations has gotten > progressively more complicated over the years. There is so much cruft > and weirdness around keeping the reserved count and outstanding counters > consistent and handling the error cases that

Re: USB upgrade fun

On 2017-10-12 21:42, Kai Hendry wrote: Thank you Austin & Chris for your replies! On Fri, 13 Oct 2017, at 01:19 AM, Austin S. Hemmelgarn wrote: Same here on a pair of 3 year old NUC's. Based on the traces and the other information, I'd be willing to bet this is probably the root cause of the

Re: Btrfs warnings in kernel 4.13.5

Juan Orti Alcaine posted on Fri, 13 Oct 2017 10:40:20 +0200 as excerpted: > Hi, > > I've upgraded my system to Fedora 27 and now I see many btrfs warnings, > although the system seems to be working fine. Is this something I should > worry about? > # uname -a Linux xenon 4.13.5-300.fc27.x86_64

[PATCH] btrfs: tree-checker: use %zu format string for size_t

We now get a harmless compile-time on 32-bit architectures: fs/btrfs/tree-checker.c: In function 'check_extent_data_item': fs/btrfs/tree-checker.c:189:70: error: format '%lu' expects argument of type 'long unsigned int', but argument 6 has type 'unsigned int' [-Werror=format=] This changes the

[PATCH] btrfs-progs: subvol list: don't print deleted subvol as TOPLEVEL

We should use entry->root_id instead of top_id to determine whether it is the toplevel subvolume. Signed-off-by: Lu Fengqi --- btrfs-list.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/btrfs-list.c b/btrfs-list.c index 6f2d8774..4ea8edfd 100644

Re: btrfs errors over NFS

On 12.10.2017 20:44, Steve Leung wrote: > Hi list, > > TL;DR: ran into some btrfs errors and weird behaviour, but things generally > seem > to work. Just posting some details in case it helps devs or other users. > > I've run into a btrfs error trying to do a -j8 build of android on a

Re: Btrfs warnings in kernel 4.13.5

2017-10-13 10:40 GMT+02:00 Juan Orti Alcaine : > Hi, > > I've upgraded my system to Fedora 27 and now I see many btrfs > warnings, although the system seems to be working fine. Is this > something I should worry about? I'm getting more warnings: [ 337.822868]

Btrfs warnings in kernel 4.13.5

Hi, I've upgraded my system to Fedora 27 and now I see many btrfs warnings, although the system seems to be working fine. Is this something I should worry about? I have a scrub running with no errors so far: # btrfs scrub status /mnt/btrfs scrub status for 038b2b48-fd2d-4565-b2b1-d07847ecca8c

Re: [PATCH 01/21] Btrfs: rework outstanding_extents

On 29.09.2017 22:43, Josef Bacik wrote: > > +static inline void btrfs_mod_outstanding_extents(struct btrfs_inode *inode, > + int mod) > +{ > + ASSERT(spin_is_locked(>lock)); > + inode->outstanding_extents += mod; > + if

Re: [PATCH] btrfs: set include path relatively

2017-10-12 21:38 GMT+09:00 David Sterba : > On Thu, Oct 12, 2017 at 11:22:24AM +0900, Naohiro Aota wrote: >> Currently, gcc is passed the include directory with full path. As a result, >> dependency files (*.o.d) also record the full path at the build time. Such >> full path