From: "Richard W.M. Jones" <rjones@redhat.com>
To: Jason Pepas <jasonpepas@gmail.com>
Cc: linux-ext4@vger.kernel.org, libguestfs@redhat.com
Subject: Re: mkfs.ext2 succeeds despite nbd write errors?
Date: Sat, 7 Nov 2015 21:02:03 +0000 [thread overview]
Message-ID: <20151107210203.GW29330@redhat.com> (raw)
In-Reply-To: <CALuDM+Aw9JCMVbQcRKaaUu+=+xvDpMgL8sUZpT2snz9Qp5DqpA@mail.gmail.com>
[Adding linux-ext4 mailing list. The original bug report is here:
https://www.redhat.com/archives/libguestfs/2015-November/msg00078.html ]
On Sat, Nov 07, 2015 at 01:22:45PM -0600, Jason Pepas wrote:
> On Sat, Nov 7, 2015 at 5:03 AM, Richard W.M. Jones <rjones@redhat.com> wrote:
> > How about 'strace mkfs.ext2 ..' and see if any system calls are
> > returning errors. That would show you whether nbd-client is throwing
> > errors away, or whether mkfs is getting the errors and ignoring them
> > (seems pretty unlikely, but you never know).
> >
> > After that, it'd be down to tracing where the errors end up in the
> > kernel.
>
> Thanks for the tip!
>
> The results are interesting. It looks like all of mkfs's pwrite()
> calls succeed, but its final fsync() calls do actually fail:
>
>
> root@debian:~# strace mkfs.ext2 /dev/nbd0 2>&1 | tee strace.out
>
> root@debian:~# cat strace.out | grep pwrite
> pwrite(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> 32768, 8187379712) = 32768
> pwrite(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> 32768, 8187412480) = 32768
> pwrite(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> 32768, 8187445248) = 32768
> ...
>
> root@debian:~# cat strace.out | grep fsync
> fsync(3) = -1 EIO (Input/output error)
> fsync(3) = -1 EIO (Input/output error)
>
>
> The fsync() calls happen just before mkfs exists success:
>
>
> root@debian:~# cat strace.out | tail
> pwrite(3, "\1\2\0\0\2\2\0\0\3\2\0\0\367{\365\37\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> 4096, 6576672768) = 4096
> fsync(3) = -1 EIO (Input/output error)
> pwrite(3, "\0\0\10\0\0\0
> \0\231\231\1\0qm\37\0\365\377\7\0\0\0\0\0\2\0\0\0\2\0\0\0"..., 1024,
> 1024) = 1024
> fsync(3) = -1 EIO (Input/output error)
> close(3) = 0
> write(1, "done\n\n", 6done
>
> ) = 6
> exit_group(0) = ?
> +++ exited with 0 +++
> root@debian:~#
>
>
> I did manage to find two calls to fsync in the e2fsprogs source which
> are not return-value-checked:
>
> https://github.com/tytso/e2fsprogs/blob/956b0f18a5ddb6815a9dff4f10a1e3125cdca9ba/misc/filefrag.c#L303
> https://github.com/tytso/e2fsprogs/blob/956b0f18a5ddb6815a9dff4f10a1e3125cdca9ba/lib/ext2fs/unix_io.c#L915
That second one looks very suspicious to me. I don't think that it's
ever right for mke2fs to ignore the return value from an fsync call,
so assuming mke2fs calls that function it's surely a bug.
> I'll see about submitting a patch there.
>
> I'm not sure where to start with hunting down why mkfs's pwrite()
> calls aren't failing. I'd look to the kernel source for that?
It looks like it's really an e2fsprogs problem, not a kernel problem.
That's pretty surprising - I wasn't expecting it.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
next parent reply other threads:[~2015-11-07 21:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CALuDM+AtyUUMFcdTOocxCw9BxQ4PBx5aeYVYwmy_UErh1MZjww@mail.gmail.com>
[not found] ` <20151107110354.GM1908@redhat.com>
[not found] ` <CALuDM+Aw9JCMVbQcRKaaUu+=+xvDpMgL8sUZpT2snz9Qp5DqpA@mail.gmail.com>
2015-11-07 21:02 ` Richard W.M. Jones [this message]
2015-11-07 23:09 ` mkfs.ext2 succeeds despite nbd write errors? Jason Pepas
2015-11-07 23:20 ` Richard W.M. Jones
2015-11-07 23:25 ` Jason Pepas
2015-11-07 23:47 ` [Libguestfs] " Jason Pepas
2015-11-07 23:23 ` Jason Pepas
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=20151107210203.GW29330@redhat.com \
--to=rjones@redhat.com \
--cc=jasonpepas@gmail.com \
--cc=libguestfs@redhat.com \
--cc=linux-ext4@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.