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 23:20:01 +0000 [thread overview]
Message-ID: <20151107232001.GX29330@redhat.com> (raw)
In-Reply-To: <CALuDM+CAE1g8-9g9_72hU3xcQnA5k8QTkSQj4rjHh2tHc8mgLw@mail.gmail.com>
On Sat, Nov 07, 2015 at 05:09:52PM -0600, Jason Pepas wrote:
> On Sat, Nov 7, 2015 at 3:02 PM, Richard W.M. Jones <rjones@redhat.com> wrote:
> >> 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.
>
> I agree the fsync() issue is an e2fsprogs problem, but as for
> specifically the pwrite() calls not getting a -1 return value, that's
> the kernel's fault, right?
I'm definitely not an expert here, but I do recall being told that
writes and reads are allowed to return an "OK" indication, but a later
close(2) or fsync(2) might fail. That is particularly a problem with NFS.
I'll leave the rest to the true experts on the ext4 mailing list.
> I've been rolling this around in my mind and I think I can see why the
> kernel would correctly make fsync() fail but not pwrite() fail. Let
> me run this by you:
>
> When a pwrite() happens, that doesn't immediately cause nbd to send a
> network packet out, and doesn't wait on a network reply before
> returning, right? It just ends up in some dirty block device queue,
> I'm guessing? And then something triggers a bunch of dirty blocks to
> get flushed out to "disk"? If that's the case, then its impossible
> for the kernel to give an accurate return code to pwrite(), because it
> doesn't know those blocks will eventually fail to be written to "disk"
> (nbd).
>
> But as for fsync(), the kernel is probably waiting until every last
> dirty sector gets written before it decides what the return code is,
> which is why we see that pwrite() isn't failing, but fsync() is
> failing.
>
> Does that make sense?
>
> I wonder if the block device were opened with O_DIRECT by e2fsprogs if
> that would cause the pwrite() calls to fail correctly?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
next prev parent reply other threads:[~2015-11-07 23:20 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 ` mkfs.ext2 succeeds despite nbd write errors? Richard W.M. Jones
2015-11-07 23:09 ` Jason Pepas
2015-11-07 23:20 ` Richard W.M. Jones [this message]
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=20151107232001.GX29330@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.