From: Guillaume Chazarain <guichaz@yahoo.fr>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: -mm merge plans for 2.6.21
Date: Fri, 09 Feb 2007 23:18:39 +0100 [thread overview]
Message-ID: <45CCF33F.1000605@yahoo.fr> (raw)
In-Reply-To: <20070208150710.1324f6b4.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]
Andrew Morton a écrit :
> factor-outstanding-i-o-error-handling.patch
> factor-outstanding-i-o-error-handling-tidy.patch
>
I still like them. But the original problem is still present.
> sync_sb_inodes-propagate-errors.patch
>
You explained in http://lkml.org/lkml/2007/1/2/238 that the mapping
flags should be set at the lowest level, but with this change I have a
hard time choosing a place to stick it. I don't like when a function
both sets the mapping flags and returns an error code, I think it should
be mutually exclusive, so that we know what to do (propagate the return
code?) and what to expect (are the mapping flags up to date?), which
seemed to be the case before this patch. For instance there is no point
in propagating an error return code up to sys_sync() as it can only drop it.
The call trace that cleared the flags, the origin of the problem, is:
void do_sync(1)
void sync_inodes(1)
void __sync_inodes(1)
void sync_inodes_sb(sb, 1)
void sync_sb_inodes(sb, WB_SYNC_ALL)
int __writeback_single_inode(inode, WB_SYNC_ALL)
int __sync_single_inode(inode, WB_SYNC_ALL)
int filemap_fdatawait(mapping)
int wait_on_page_writeback_range(mapping)
int test_and_clear(...)
re-setting the flag at a too low level, would mean it is still set after
a msync() or fsync() that could return the status to its caller. My
interpretation is that low level functions up to
__writeback_single_inode() can be used by fsync() and the like that can
return the error to their caller, unlike high level functions starting
at sync_sb_inodes() that don't need a return value as their caller can
do nothing with it. So re-setting the flag in sync_sb_inodes() just
after __writeback_single_inode() looks right to me, and I propose the
exact same patch as the first time.
> block_write_full_page-handle-enospc.patch
>
It seems to me that __block_write_full_page is always called more or
less directly from __mpage_writepage, and the latter handles enospc in
the mapping flags. So I am not sure this patch is needed.
Thanks.
--
Guillaume
[-- Attachment #2: sync_sb_inodes_handle_error.patch --]
[-- Type: text/x-patch, Size: 2199 bytes --]
I/O errors could go unnoticed when syncing, for example the following code could
write a file bigger than 10Mib on a 10Mib filesystem. With this patch, msync()
will report the error originally encountered by sync(). Tuning the number of
sync may be needed to reproduce the bug.
make_file.c:
#include <unistd.h>
#include <sys/fcntl.h>
#include <sys/mman.h>
#include <string.h>
#include <stdio.h>
#define NR_SYNC 3 /* Adjust me if needed */
#define SIZE ((10 << 20) + (100 << 10))
int main(void)
{
int i, fd;
char *mapping;
fd = open("mnt/file", O_RDWR | O_CREAT, 0600);
if (fd < 0) {
perror("open");
return 1;
}
if (ftruncate(fd, SIZE) < 0) {
perror("ftruncate");
return 1;
}
mapping = mmap(NULL, SIZE, PROT_WRITE, MAP_SHARED, fd, 0);
if (mapping == MAP_FAILED) {
perror("mmap");
return 1;
}
memset(mapping, 0xFF, SIZE);
for (i = 0; i < NR_SYNC; i++)
sync();
if (msync(mapping, SIZE, MS_SYNC) < 0) {
perror("msync");
return 1;
}
if (close(fd) < 0) {
perror("close");
return 1;
}
puts("File written successfully => bad!\n");
return 0;
}
#!/bin/sh
dd if=/dev/zero of=fs.10M bs=10M count=0 seek=1
mkfs.ext2 -qF fs.10M
mkdir mnt
mount fs.10M mnt -o loop
./make_file
Signed-off-by: Guillaume Chazarain <guichaz@yahoo.fr>
---
fs-writeback.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -r ecb3a0d111ec fs/fs-writeback.c
--- a/fs/fs-writeback.c Fri Feb 09 15:31:50 2007 +0100
+++ b/fs/fs-writeback.c Fri Feb 09 23:10:47 2007 +0100
@@ -327,6 +327,7 @@ sync_sb_inodes(struct super_block *sb, s
struct address_space *mapping = inode->i_mapping;
struct backing_dev_info *bdi = mapping->backing_dev_info;
long pages_skipped;
+ int ret;
if (!bdi_cap_writeback_dirty(bdi)) {
list_move(&inode->i_list, &sb->s_dirty);
@@ -376,7 +377,8 @@ sync_sb_inodes(struct super_block *sb, s
BUG_ON(inode->i_state & I_FREEING);
__iget(inode);
pages_skipped = wbc->pages_skipped;
- __writeback_single_inode(inode, wbc);
+ ret = __writeback_single_inode(inode, wbc);
+ mapping_set_error(mapping, ret);
if (wbc->sync_mode == WB_SYNC_HOLD) {
inode->dirtied_when = jiffies;
list_move(&inode->i_list, &sb->s_dirty);
next prev parent reply other threads:[~2007-02-09 22:18 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-08 23:07 -mm merge plans for 2.6.21 Andrew Morton
2007-02-08 23:12 ` Roland Dreier
2007-02-08 23:29 ` Jan Engelhardt
2007-02-08 23:44 ` Andrew Morton
2007-02-09 15:02 ` Thomas Gleixner
2007-02-09 10:57 ` Frederik Deweerdt
2007-02-09 11:24 ` Arjan van de Ven
2007-02-09 11:39 ` Andrew Morton
2007-02-09 12:32 ` Arjan van de Ven
2007-02-09 14:05 ` deweerdt
2007-02-09 13:04 ` Andi Kleen
2007-02-09 12:27 ` Jan Engelhardt
2007-02-10 11:42 ` Arnd Bergmann
2007-02-10 14:19 ` Frederik Deweerdt
2007-02-08 23:34 ` Kyle McMartin
2007-02-08 23:53 ` Andrew Morton
2007-02-09 0:55 ` Paul Mackerras
2007-02-09 1:00 ` Andrew Morton
2007-02-09 5:32 ` Bharata B Rao
2007-02-09 8:26 ` Sébastien Dugué
2007-02-09 9:05 ` Andrew Morton
2007-02-09 10:10 ` Sébastien Dugué
2007-02-09 9:54 ` Lenar Lõhmus
2007-02-09 10:12 ` Andrew Morton
2007-02-09 12:48 ` James
2007-02-09 12:59 ` Lenar Lõhmus
2007-02-09 17:35 ` David Woodhouse
2007-02-09 21:45 ` Andrew Morton
2007-02-09 21:49 ` Russell King
2007-02-09 21:53 ` David Woodhouse
2007-02-09 22:03 ` Russell King
2007-02-09 22:12 ` David Woodhouse
2007-02-09 22:42 ` David Woodhouse
2007-02-10 2:05 ` Oleg Verych
2007-02-09 22:00 ` Andrew Morton
2007-02-09 22:06 ` Russell King
2007-02-09 21:59 ` David Woodhouse
2007-02-09 22:50 ` Davide Libenzi
2007-02-10 10:22 ` Heiko Carstens
2007-02-10 10:32 ` David Woodhouse
2007-02-10 21:34 ` Ralf Baechle
2007-02-11 4:53 ` Davide Libenzi
2007-02-11 15:33 ` David Woodhouse
2007-02-11 16:09 ` Ralf Baechle
2007-02-11 16:14 ` Heiko Carstens
2007-02-11 16:34 ` Davide Libenzi
2007-02-11 18:01 ` Ralf Baechle
2007-02-10 21:05 ` Ralf Baechle
2007-02-11 10:37 ` Andi Kleen
2007-02-10 13:03 ` Andi Kleen
2007-02-09 19:37 ` Alan
2007-02-09 21:51 ` Andrew Morton
2007-02-10 1:15 ` Carl-Daniel Hailfinger
2007-02-10 1:29 ` Andrew Morton
2007-02-10 13:06 ` Andi Kleen
2007-02-10 13:48 ` Alan
2007-02-10 14:43 ` Andi Kleen
2007-02-12 20:56 ` Doug Thompson
2007-02-12 21:46 ` Andi Kleen
2007-02-12 22:45 ` Doug Thompson
2007-02-09 22:18 ` Guillaume Chazarain [this message]
2007-02-10 9:58 ` -mm merge plans for 2.6.21 -- md-dm-reduce-stack-usage-with-stacked-block-devices.patch Heiko Carstens
2007-02-10 22:35 ` Alasdair G Kergon
2007-02-11 0:31 ` -mm merge plans for 2.6.21 Dave Jones
-- strict thread matches above, loose matches on Subject: below --
2007-02-09 2:57 Parag Warudkar
2007-02-09 3:05 ` Andrew Morton
[not found] <fa.7Z67qjqJwFP7+8QiVtu5tq6CZyU@ifi.uio.no>
[not found] ` <fa.4Y/nCUol/tGEodoOl/Jm9nf2AEA@ifi.uio.no>
[not found] ` <fa.TgZy4z2lRhwhAWCUE8IuGvMVUCU@ifi.uio.no>
[not found] ` <fa.HINMjdGzCuxlEiWtVvmNz7Pv9Pc@ifi.uio.no>
[not found] ` <fa.2ClW7C4ZyCP9QlT4vg7CbzjSqwg@ifi.uio.no>
2007-02-10 17:04 ` Robert Hancock
2007-01-12 23:19 ` Frederik Deweerdt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45CCF33F.1000605@yahoo.fr \
--to=guichaz@yahoo.fr \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox