Hi David,
I think my previous email may have failed to send.
Can you merge my patch below?
It's a minor update that I think improves readability.
Thanks,
Sahil
On 04/19/2017 05:43 AM, Sahil Kang wrote:
Hi,
This is my first patch so it's a minor code change.
I think removing the early continue
run_next_block() ignores the return value of read_tree_block() and
always returns success status. This might cause deal_root_from_list()
to loop infinitely when reading metadata block fails. This bug fixes
the issue by extracting and returning the error code from the return
value of read_tree_block
v3: wb_err_t -> errseq_t
clean up places that re-set errors after calling filemap_* functions
v2: introduce wb_err_t, use atomics
Apologies for the wide posting here, but this touches a lot of areas.
This is v3 of the patchset to improve how we're tracking and reporting
errors that occur duri
Signed-off-by: Jeff Layton
Reviewed-by: Jan Kara
Reviewed-by: Matthew Wilcox
---
fs/buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 9196f2a270da..70638941066d 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -483,7 +483,7 @@ static void
launder_page is just writeback under the page lock. We still need to
mark the mapping for errors there when they occur.
Signed-off-by: Jeff Layton
---
fs/9p/vfs_addr.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/9p/vfs_addr.c b/fs/9p/vfs_addr.c
index adaf6f6dd858..
If writepage fails during a page migration, then we need to ensure that
fsync will see it by flagging the mapping.
Signed-off-by: Jeff Layton
---
mm/migrate.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mm/migrate.c b/mm/migrate.c
index 738f1d5f8350..3a59830bdae2 100
Now that we don't clear writeback errors after fetching them, there is
no need to reset them. This is also potentially racy.
Signed-off-by: Jeff Layton
---
fs/jbd2/commit.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
inde
In some places, it's trying to reset the mapping error after calling
filemap_fdatawait. That's no longer required. Also, turn several
filemap_fdatawrite+filemap_fdatawait calls into filemap_write_and_wait.
That will at least return writeback errors that occur during the write
phase.
Signed-off-by:
They're no longer used.
Signed-off-by: Jeff Layton
---
include/linux/pagemap.h | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index 32512ffc15fa..9593eac41499 100644
--- a/include/linux/pagemap.h
+++ b/include/linu
The -EIO returned here can end up overriding whatever error is marked in
the address space, and be returned at fsync time, even when there is a
more appropriate error stored in the mapping.
Read errors are also sometimes tracked on a per-page level using
PG_error. Suppose we have a read error on a
Don't try to check PageError since that's potentially racy and not
necessarily going to be set after writepage errors out.
Instead, sample the mapping error early on, and use that value to tell
us whether we got a writeback error since then.
Signed-off-by: Jeff Layton
---
mm/page-writeback.c |
Now that writeback errors are handled on a per-file basis using the new
sequence counter method at the vfs layer, we no longer need to re-set
errors in the mapping after doing writeback in non-fsync codepaths.
Also, fix up some bogus comments.
Signed-off-by: Jeff Layton
---
fs/cifs/cifsfs.c |
Now that we have a better way to store and report errors that occur
during writeback, we need to convert the existing codebase to use it. We
could just adapt all of the filesystem code and related infrastructure
to the new API, but that's a lot of churn.
When it comes to setting errors in the mapp
Most filesystems currently use mapping_set_error and
filemap_check_errors for setting and reporting/clearing writeback errors
at the mapping level. filemap_check_errors is indirectly called from
most of the filemap_fdatawait_* functions and from
filemap_write_and_wait*. These functions are called f
An errseq_t is a way of recording errors in one place, and allowing any
number of "subscribers" to tell whether an error has been set again
since a previous time.
It's implemented as an unsigned 32-bit value that is managed with atomic
operations. The low order bits are designated to hold an error
This ensures that we see errors on fsync when writeback fails.
Signed-off-by: Jeff Layton
---
fs/fuse/file.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index ec238fb5a584..07d0efcb050c 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -1669,6 +1669,7 @@
Signed-off-by: Jeff Layton
---
fs/cifs/file.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 21d404535739..4b696a23b0b1 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -2234,14 +2234,16 @@ cifs_writepage_locked(struct page
In a later patch, we're going to want to make the fsync codepath not do
a TestClearPageError call as that can override the error set in the
address space. To do that though, we need to ensure that filesystems
that are relying on the PG_error bit for reporting writeback errors
also set an error in t
In order to get proper error codes from fsync, we must set an error in
the mapping range when writeback fails.
Signed-off-by: Jeff Layton
---
fs/dax.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/dax.c b/fs/dax.c
index 85abd741253d..9b6b04030c3f 100644
--- a/fs/dax.c
Signed-off-by: Lakshmipathi.G
---
tests/fsck-tests/006-bad-root-items/test.sh| 6 +++---
tests/fsck-tests/012-leaf-corruption/test.sh | 24 +++---
tests/fsck-tests/013-extent-tree-rebuild/test.sh | 22 ++--
tests/fsck-tests/018-leaf-crossing-stripe
Orangefs doesn't do buffered writes yet, so there's no point in
initiating and waiting for writeback.
Signed-off-by: Jeff Layton
---
fs/orangefs/file.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/fs/orangefs/file.c b/fs/orangefs/file.c
index e6bbc8083d77..17ab42c4db52
ext2 currently does a test+clear of the AS_EIO flag, which is
is problematic for some coming changes.
What we really need to do instead is call filemap_check_errors
in __generic_file_fsync after syncing out the buffers. That
will be sufficient for this case, and help other callers detect
these err
The callers all set it to 1.
Also, make it clear that this function will not set any sort of AS_*
error, and that the caller must do so if necessary. No existing caller
uses this on normal files, so none of them need it.
Also, add __must_check here since, in general, the callers need to
handle an
The error code should be negative. Since this ends up in the default
case anyway, this is harmless, but it's less confusing to negate it.
Also, later patches will require a negative error code here.
Signed-off-by: Jeff Layton
Reviewed-by: Ross Zwisler
Reviewed-by: Jan Kara
Reviewed-by: Matthew
Example usage:
btrfs inspect-internal dump-csum /btrfs/50gbfile /dev/sda4
csum for /btrfs/50gbfile dumped to /btrfs/50gbfile.csumdump
Signed-off-by: Lakshmipathi.G
---
Makefile | 3 +-
cmds-inspect-dump-csum.c | 256 +++
cmds-inspect-
This is just an RFC set for now. I've numbered it 999 for the moment so
as not to collide with tests being added.
I'm working on a set of kernel patches to change how writeback errors
are handled and reported in the kernel. Instead of reporting a
writeback error to only the first fsync caller on t
- Original Message -
| In some places, it's trying to reset the mapping error after calling
| filemap_fdatawait. That's no longer required. Also, turn several
| filemap_fdatawrite+filemap_fdatawait calls into filemap_write_and_wait.
| That will at least return writeback errors that occur du
On Mon, Apr 24, 2017 at 09:45:51AM -0400, Jeff Layton wrote:
> With the patch series above, ext4 now passes. xfs and btrfs end up in
> r/o mode after the test. xfs returns -EIO at that point though, and
> btrfs returns -EROFS. What behavior we actually want there, I'm not
> certain. We might be abl
> out:
> inode_unlock(inode);
> - return ret;
> + err = filemap_check_errors(inode->i_mapping);
> + return ret ? : err;
Can you spell out the whole unary operation instead of this weird GCC
extension?
Otherwise looks fine:
Reviewed-by: Christoph Hellwig
--
To unsubscribe from
Looks fine,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Looks fine,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Looks fine,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Looks fine,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Looks fine,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Looks fine,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Looks fine,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Apr 24, 2017 at 09:22:48AM -0400, Jeff Layton wrote:
> launder_page is just writeback under the page lock. We still need to
> mark the mapping for errors there when they occur.
>
> Signed-off-by: Jeff Layton
Looks fine,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: s
Looks fine,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Apr 24, 2017 at 09:22:50AM -0400, Jeff Layton wrote:
> Signed-off-by: Jeff Layton
> ---
> fs/cifs/file.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/fs/cifs/file.c b/fs/cifs/file.c
> index 21d404535739..4b696a23b0b1 100644
> --- a/fs/cifs/file.c
>
I have a btrfs file system with a few thousand snapshots. When I
attempted to delete 20 or so of them the problems started.
The disks are being read but except for the first few minutes there
are no writes.
Memory usage keeps growing until all the memory (24 Gb) is used in a
few hours. Eventuall
On Mon 24-04-17 09:22:43, Jeff Layton wrote:
> ext2 currently does a test+clear of the AS_EIO flag, which is
> is problematic for some coming changes.
>
> What we really need to do instead is call filemap_check_errors
> in __generic_file_fsync after syncing out the buffers. That
> will be sufficie
On Mon 24-04-17 09:22:45, Jeff Layton wrote:
> In order to get proper error codes from fsync, we must set an error in
> the mapping range when writeback fails.
>
> Signed-off-by: Jeff Layton
So I'm fine with the change but please expand the changelog to something
like:
DAX currently doesn't set
On Mon 24-04-17 09:22:47, Jeff Layton wrote:
> If writepage fails during a page migration, then we need to ensure that
> fsync will see it by flagging the mapping.
>
> Signed-off-by: Jeff Layton
Looks good to me. You can add:
Reviewed-by: Jan Kara
On Mon 24-04-17 09:22:48, Jeff Layton wrote:
> launder_page is just writeback under the page lock. We still need to
> mark the mapping for errors there when they occur.
>
> Signed-off-by: Jeff Layton
Looks good. You can add:
Reviewed-by: Jan Kara
On Mon 24-04-17 09:22:49, Jeff Layton wrote:
> This ensures that we see errors on fsync when writeback fails.
>
> Signed-off-by: Jeff Layton
Hum, but do we really want to clobber mapping errors with temporary stuff
like ENOMEM? Or do you want to handle that in mapping_set_error?
On Mon, 2017-04-24 at 10:12 -0400, Bob Peterson wrote:
> - Original Message -
> > In some places, it's trying to reset the mapping error after calling
> > filemap_fdatawait. That's no longer required. Also, turn several
> > filemap_fdatawrite+filemap_fdatawait calls into filemap_write_and_w
On Mon, Apr 24, 2017 at 9:27 AM, Fred Van Andel wrote:
> I have a btrfs file system with a few thousand snapshots. When I
> attempted to delete 20 or so of them the problems started.
>
> The disks are being read but except for the first few minutes there
> are no writes.
>
> Memory usage keeps gr
On Mon, 2017-04-24 at 18:04 +0200, Jan Kara wrote:
> On Mon 24-04-17 09:22:49, Jeff Layton wrote:
> > This ensures that we see errors on fsync when writeback fails.
> >
> > Signed-off-by: Jeff Layton
>
> Hum, but do we really want to clobber mapping errors with temporary stuff
> like ENOMEM? Or
On Mon, 2017-04-24 at 08:27 -0700, Christoph Hellwig wrote:
> On Mon, Apr 24, 2017 at 09:22:50AM -0400, Jeff Layton wrote:
> > Signed-off-by: Jeff Layton
> > ---
> > fs/cifs/file.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/fs/cifs/file.c b/fs/cifs/
Hi,
- Original Message -
| On Mon, 2017-04-24 at 10:12 -0400, Bob Peterson wrote:
| > > + filemap_write_and_wait_range(mapping, gl->gl_vm.start, gl->gl_vm.end);
| >
| > This should probably have "error = ", no?
| >
|
| This error is discarded in the current code after resetting the erro
On Mon, 2017-04-24 at 13:41 -0400, Bob Peterson wrote:
> Hi,
>
> - Original Message -
> > On Mon, 2017-04-24 at 10:12 -0400, Bob Peterson wrote:
> > > > + filemap_write_and_wait_range(mapping, gl->gl_vm.start,
> > > > gl->gl_vm.end);
> > >
> > > This should probably have "error = "
I've been running it here...
Acked-by: Mike Marshall
On Mon, Apr 24, 2017 at 11:23 AM, Christoph Hellwig wrote:
> Looks fine,
>
> Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More
Good day,
I hope that you have a wonderful health, I saw your profile and I would
like to discuss an important and confidential business with you, your
profile is perfect for a project i need your assistance for that so ,
let me know if you agree and I will send you all the necessary details.
On Mon, Apr 24, 2017 at 09:22:45AM -0400, Jeff Layton wrote:
> In order to get proper error codes from fsync, we must set an error in
> the mapping range when writeback fails.
>
> Signed-off-by: Jeff Layton
Works fine in some error injection testing.
Tested-by: Ross Zwisler
> ---
> fs/dax.c
On 04/19/2017 01:45 AM, Christoph Hellwig wrote:
> On Fri, Apr 14, 2017 at 07:02:54AM -0500, Goldwyn Rodrigues wrote:
>> From: Goldwyn Rodrigues
>>
>
>> +/* Request queue supports BIO_NOWAIT */
>> +queue_flag_set_unlocked(QUEUE_FLAG_NOWAIT, q);
>
> BIO_NOWAIT is gone. And the comment
At 04/24/2017 11:27 PM, Fred Van Andel wrote:
I have a btrfs file system with a few thousand snapshots. When I
attempted to delete 20 or so of them the problems started.
The disks are being read but except for the first few minutes there
are no writes.
Memory usage keeps growing until all th
On 04/24/2017 03:10 PM, Goldwyn Rodrigues wrote:
>
>
> On 04/19/2017 01:45 AM, Christoph Hellwig wrote:
>> On Fri, Apr 14, 2017 at 07:02:54AM -0500, Goldwyn Rodrigues wrote:
>>> From: Goldwyn Rodrigues
>>>
>>
>>> + /* Request queue supports BIO_NOWAIT */
>>> + queue_flag_set_unlocked(QUEUE_F
I have a remote machine with a filesystem for which I periodically take
incremental snapshots for historical reasons. These snapshots are
stored in an archival filesystem tree on a file server. Older snapshots
are removed and newer ones added on a rotational basis. I need to be
able to backu
Chris Murphy posted on Mon, 24 Apr 2017 11:02:02 -0600 as excerpted:
> On Mon, Apr 24, 2017 at 9:27 AM, Fred Van Andel
> wrote:
>> I have a btrfs file system with a few thousand snapshots. When I
>> attempted to delete 20 or so of them the problems started.
>>
>> The disks are being read but exc
On 25/04/17 03:26, Qu Wenruo wrote:
IIRC qgroup for subvolume deletion will cause full subtree rescan
which can cause tons of memory.
Could it be this bad, 24GB of RAM for a 5.6TB volume? What does it even
use this absurd amount of memory for? Is it swappable?
Haven't read about RAM limitatio
At 04/25/2017 01:33 PM, Marat Khalili wrote:
On 25/04/17 03:26, Qu Wenruo wrote:
IIRC qgroup for subvolume deletion will cause full subtree rescan
which can cause tons of memory.
Could it be this bad, 24GB of RAM for a 5.6TB volume? What does it even
use this absurd amount of memory for? Is
61 matches
Mail list logo
