2013-07-24 08:59:34

by Robert Yang

[permalink] [raw]
Subject: e2fsprogs/debugfs/write: Input/output error when file size is zero


Hello experts,

I met a "Input/output error" problem when used debugfs' command "write"
to copy a zero size file to ext4 fs, here are the steps to reproduce the
problem:

$ dd if=/dev/zero of=test.img count=1M bs=1k
$ mkfs.ext4 -F test.img
$ touch emptyfile
$ debugfs -R "write emptyfile emptyfile" -w test.img
$ mkdir mnt
$ mount test.img mnt/
$ ls mnt/emptyfile
ls: cannot access mnt/emptyfile: Input/output error

The degbufs is from the up-to-date git repo, the ext2 and ext3 work well,
I think that it is caused by the EXT4_EXTENTS_FL, it works well if we
turn off the EXT4_EXTENTS_FL when the file size is zero, but this is not
a correct fix, would you please give me some instructions so that I can
fix it?

--
Thanks

Robert


2013-07-24 15:09:21

by Eric Sandeen

[permalink] [raw]
Subject: Re: e2fsprogs/debugfs/write: Input/output error when file size is zero

On 7/24/13 3:59 AM, Robert Yang wrote:
>
> Hello experts,
>
> I met a "Input/output error" problem when used debugfs' command "write"
> to copy a zero size file to ext4 fs, here are the steps to reproduce the
> problem:
>
> $ dd if=/dev/zero of=test.img count=1M bs=1k
> $ mkfs.ext4 -F test.img
> $ touch emptyfile
> $ debugfs -R "write emptyfile emptyfile" -w test.img
> $ mkdir mnt
> $ mount test.img mnt/
> $ ls mnt/emptyfile
> ls: cannot access mnt/emptyfile: Input/output error
>
> The degbufs is from the up-to-date git repo, the ext2 and ext3 work well,
> I think that it is caused by the EXT4_EXTENTS_FL, it works well if we
> turn off the EXT4_EXTENTS_FL when the file size is zero, but this is not
> a correct fix, would you please give me some instructions so that I can
> fix it?

When reporting problems like this it's helpful to include which kernel version
you tested, all the error messages (including dmesg), etc.

But on upstream it persists, and when we do the ls, we get:

[40992.729130] EXT4-fs error (device loop0): ext4_ext_check_inode:464: inode #12: comm ls: bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)

so it seems that debugfs has created a corrupt inode in the image.

I'll send a patch.



2013-07-24 15:11:31

by Eric Sandeen

[permalink] [raw]
Subject: [PATCH] debugfs: properly set up extent header in do_write

do_write doesn't fully set up the first extent header on a new
inode, so if we write a 0-length file, and don't write any data
to the new file, we end up creating something that looks corrupt
to kernelspace:

EXT4-fs error (device loop0): ext4_ext_check_inode:464: inode #12: comm ls: bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)

Do something similar to ext4_ext_tree_init() here, and
fill out the first extent header upon creation to avoid this.

Reported-by: Robert Yang <[email protected]>
Signed-off-by: Eric Sandeen <[email protected]>
---

diff --git a/debugfs/debugfs.c b/debugfs/debugfs.c
index dcf16e2..2660218 100644
--- a/debugfs/debugfs.c
+++ b/debugfs/debugfs.c
@@ -1677,8 +1677,19 @@ void do_write(int argc, char *argv[])
inode.i_links_count = 1;
inode.i_size = statbuf.st_size;
if (current_fs->super->s_feature_incompat &
- EXT3_FEATURE_INCOMPAT_EXTENTS)
+ EXT3_FEATURE_INCOMPAT_EXTENTS) {
+ int i;
+ struct ext3_extent_header *eh;
+
+ eh = (struct ext3_extent_header *) &inode.i_block[0];
+ eh->eh_depth = 0;
+ eh->eh_entries = 0;
+ eh->eh_magic = EXT3_EXT_MAGIC;
+ i = (sizeof(inode.i_block) - sizeof(*eh)) /
+ sizeof(struct ext3_extent);
+ eh->eh_max = ext2fs_cpu_to_le16(i);
inode.i_flags |= EXT4_EXTENTS_FL;
+ }
if (debugfs_write_new_inode(newfile, &inode, argv[0])) {
close(fd);
return;


2013-07-25 06:19:03

by Robert Yang

[permalink] [raw]
Subject: Re: [PATCH] debugfs: properly set up extent header in do_write


Hi Eric,

Thank you very much, it worked well with your patch, I've tested it on
Fedora 18 x86_64, the kernel is 3.6.10-4.fc18.x86_64.

Tested-by: Robert Yang <[email protected]>

// Robert

On 07/24/2013 11:11 PM, Eric Sandeen wrote:
> do_write doesn't fully set up the first extent header on a new
> inode, so if we write a 0-length file, and don't write any data
> to the new file, we end up creating something that looks corrupt
> to kernelspace:
>
> EXT4-fs error (device loop0): ext4_ext_check_inode:464: inode #12: comm ls: bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
>
> Do something similar to ext4_ext_tree_init() here, and
> fill out the first extent header upon creation to avoid this.
>
> Reported-by: Robert Yang <[email protected]>
> Signed-off-by: Eric Sandeen <[email protected]>
> ---
>
> diff --git a/debugfs/debugfs.c b/debugfs/debugfs.c
> index dcf16e2..2660218 100644
> --- a/debugfs/debugfs.c
> +++ b/debugfs/debugfs.c
> @@ -1677,8 +1677,19 @@ void do_write(int argc, char *argv[])
> inode.i_links_count = 1;
> inode.i_size = statbuf.st_size;
> if (current_fs->super->s_feature_incompat &
> - EXT3_FEATURE_INCOMPAT_EXTENTS)
> + EXT3_FEATURE_INCOMPAT_EXTENTS) {
> + int i;
> + struct ext3_extent_header *eh;
> +
> + eh = (struct ext3_extent_header *) &inode.i_block[0];
> + eh->eh_depth = 0;
> + eh->eh_entries = 0;
> + eh->eh_magic = EXT3_EXT_MAGIC;
> + i = (sizeof(inode.i_block) - sizeof(*eh)) /
> + sizeof(struct ext3_extent);
> + eh->eh_max = ext2fs_cpu_to_le16(i);
> inode.i_flags |= EXT4_EXTENTS_FL;
> + }
> if (debugfs_write_new_inode(newfile, &inode, argv[0])) {
> close(fd);
> return;
>
>
>