linux-ext4 - Re: [Libguestfs] mkfs.ext2 succeeds despite nbd write errors?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALuDM+CAE1g8-9g9_72hU3xcQnA5k8QTkSQj4rjHh2tHc8mgLw@mail.gmail.com>
Date:	Sat, 7 Nov 2015 17:09:52 -0600
From:	Jason Pepas <jasonpepas@...il.com>
To:	"Richard W.M. Jones" <rjones@...hat.com>
Cc:	libguestfs@...hat.com, linux-ext4@...r.kernel.org
Subject: Re: [Libguestfs] mkfs.ext2 succeeds despite nbd write errors?

On Sat, Nov 7, 2015 at 3:02 PM, Richard W.M. Jones <rjones@...hat.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'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?

-jason
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html