On 2017/5/9 9:49, Chao Yu wrote:
> Hi Jaegeuk,
>
> On 2017/5/9 5:23, Jaegeuk Kim wrote:
>> Hi Chao,
>>
>> I can't see a strong reason to split meta from data/node and rename the
>> existing
>> function names. Instead, how about keeping the existing one while adding some
>> page types to deal with
On 05/09, Weichao Guo wrote:
> We should call stat_inc_bggc_count only after BG_GC has been performed
> successfully. Otherwise, BG_GC count may be larger than total count
> when f2fs_gc failed, e.g., no victim was selected.
BTW, if we do this, we can't monitor the call count of BGGC. Actually we
On Tue, 2017-05-09 at 11:49 -0400, Jeff Layton wrote:
> I waxed a little loquacious here, but I figured that more detail was
> better, and writeback error handling is so hard to get right.
>
> Cc: Jan Kara
> Signed-off-by: Jeff Layton
> ---
> Documentation/filesystems/vfs.txt | 54
> ++
With btrfs, we can't really put the log on a separate device. What we
can do however is mirror the metadata across two devices and put the
data on a single device. When we turn on dmerror then the metadata can
fall back to using the other mirror while the data errors out.
Signed-off-by: Jeff Layto
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 the file, I aim
to make the kernel report them once on every file description.
This patch adds a test for the new b
I've numbered the new test as 999 for the moment so as not to collide with
tests being added while I've been working on this. I can change that and
resend if this should go in.
I'm working on a set of kernel patches to change how writeback errors
are handled and reported in the kernel. Instead of
The writeback error handling test requires that you put the journal on a
separate device. This allows us to use dmerror to simulate data
writeback failure, without affecting the journal.
xfs already has infrastructure for this (a'la $SCRATCH_LOGDEV), so wire
up the ext4 code so that it can do the
Hi
We can supply high quality motorcycle brake pad in sintered material and
semi-metallic
We have good quality material and cheaper prices
if you have any requirment,you can click our website :www.tracyelise.com
Thanks
best regards
Motodios Limited
kian
This no longer applies with the new writeback error tracking and
reporting infrastructure.
Signed-off-by: Jeff Layton
---
mm/memory-failure.c | 35 +--
1 file changed, 5 insertions(+), 30 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 4
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
I waxed a little loquacious here, but I figured that more detail was
better, and writeback error handling is so hard to get right.
Cc: Jan Kara
Signed-off-by: Jeff Layton
---
Documentation/filesystems/vfs.txt | 54 ---
1 file changed, 45 insertions(+), 9 dele
Signed-off-by: Jeff Layton
---
include/linux/pagemap.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index 9593eac41499..9b453eae0aa1 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -27,6 +27,20 @@ enum
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:
Drop the ERROR_WRITE flag and convert the error field in the context to
a errseq_t. Add a new wb_err_cursor to track the reporting of the
errseq_t. In principle, we could use the f_wb_err field in struct file
for that, but that's problematic with the stock reporting in call_fsync.
Signed-off-by: J
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 |
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
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
This ensures that we see errors on fsync when writeback fails.
Signed-off-by: Jeff Layton
Reviewed-by: Christoph Hellwig
---
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/f
I noticed on xfs that I could still sometimes get back an error on fsync
on a fd that was opened after the error condition had been cleared.
The problem is that the buffer code sets the write_io_error flag and
then later checks that flag to set the error in the mapping. That flag
perisists for qui
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
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
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
Since it returns errors in a way similar to fsync, have it use the same
method for returning previously-reported writeback errors.
Signed-off-by: Jeff Layton
---
fs/sync.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/fs/sync.c b/fs/sync.c
index 11ba023434b1..
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 |
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
Signed-off-by: Jeff Layton
Reviewed-by: Christoph Hellwig
---
fs/cifs/file.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 21d404535739..0bee7f8d91ad 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -2234,14 +2234,16 @@
Nothing checks its return value.
Signed-off-by: Jeff Layton
---
fs/btrfs/disk-io.c | 6 +++---
fs/btrfs/disk-io.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index eb1ee7b6f532..8c479bd5534a 100644
--- a/fs/btrfs/disk-io.c
+++ b/
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
Reviewed-by: Jan Kara
Reviewed-by: Christoph Hellwig
---
fs/9p/vfs_addr.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/f
Jan's description for this patch is much better than mine, so I'm
quoting it verbatim here:
DAX currently doesn't set errors in the mapping when cache flushing
fails in dax_writeback_mapping_range(). Since this function can get
called only from fsync(2) or sync(2), this is actually as good as it c
v4: several more cleanup patches
documentation and kerneldoc comment updates
fix bugs in gfs2 patches
make sync_file_range use same error reporting semantics
bugfixes in buffer.c
convert nfs to new scheme (maybe bogus, can be dropped)
v3: wb_err_t -> errseq_t conversion
cle
Orangefs doesn't do buffered writes yet, so there's no point in
initiating and waiting for writeback.
Signed-off-by: Jeff Layton
Reviewed-by: Christoph Hellwig
Acked-by: Mike Marshall
---
fs/orangefs/file.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/fs/orangefs/fil
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
Signed-off-by: Jeff Layton
---
include/linux/fs.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 7251f7bb45e8..38adefd8e2a0 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1252,8 +1252,6 @@ extern void f_delown(struct file *filp);
Signed-off-by: Jeff Layton
Reviewed-by: Jan Kara
Reviewed-by: Matthew Wilcox
Reviewed-by: Christoph Hellwig
---
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
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
On Mon, 2017-04-24 at 08:00 -0700, Christoph Hellwig wrote:
> 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
On 2017/5/9 19:37, Weichao Guo wrote:
> By default, f2fs_gc returns -EINVAL in general error cases, e.g., no victim
> was selected. However, the default errno may be overwritten in two cases:
> gc_more and BG_GC -> FG_GC. We should return consistent errno in such cases.
How about clean up this pat
38 matches
Mail list logo
