All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	davem@davemloft.net, sparclinux@vger.kernel.org,
	linux-kernel@vger.kernel.org, jens.axboe@oracle.com
Subject: Re: [SUGGESTION]: drop virtual merge accounting in I/O requests
Date: Tue, 15 Jul 2008 12:15:08 +0000	[thread overview]
Message-ID: <487C94CC.3090402@firstfloor.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0807150759430.12202@devserv.devel.redhat.com>

Mikulas Patocka wrote:
>>> BTW. what should the block device driver do when it receives a mapping
>>> error? (if it aborts the request and it was write request, there will be
>>> data corruption).
>>
>> I'm not sure how a aborted request can corrupt data on disk.
> 
> Writes are done by an async daemon and no one checks for their
> completion status. If there are three writes to directory, inode table
> and inode bitmap and one of these writes fail, there's no code to undo
> the other two. So the filesystem will be corrupted on write failure.

Normally journaling in ordered mode takes care of that. The transaction
is not committed until all earlier data has been successfully written.
And even the other fs typically turn the file system read only
on IO error to prevent further corruption.

Bigger issue is when the IOMMU mapping fails, but the driver doesn't have
error handling code. In the early days of the x86-64 GART IOMMU I managed
to corrupt a few super blocks this way because random data would be written then.

The block drivers have this pretty much all fixed these days, but in some other
areas (like network drivers) it looks much worse. So if your file system is
actually a network file system this might be a problem.

-Andi

WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <andi@firstfloor.org>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	davem@davemloft.net, sparclinux@vger.kernel.org,
	linux-kernel@vger.kernel.org, jens.axboe@oracle.com
Subject: Re: [SUGGESTION]: drop virtual merge accounting in I/O requests
Date: Tue, 15 Jul 2008 14:15:08 +0200	[thread overview]
Message-ID: <487C94CC.3090402@firstfloor.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0807150759430.12202@devserv.devel.redhat.com>

Mikulas Patocka wrote:
>>> BTW. what should the block device driver do when it receives a mapping
>>> error? (if it aborts the request and it was write request, there will be
>>> data corruption).
>>
>> I'm not sure how a aborted request can corrupt data on disk.
> 
> Writes are done by an async daemon and no one checks for their
> completion status. If there are three writes to directory, inode table
> and inode bitmap and one of these writes fail, there's no code to undo
> the other two. So the filesystem will be corrupted on write failure.

Normally journaling in ordered mode takes care of that. The transaction
is not committed until all earlier data has been successfully written.
And even the other fs typically turn the file system read only
on IO error to prevent further corruption.

Bigger issue is when the IOMMU mapping fails, but the driver doesn't have
error handling code. In the early days of the x86-64 GART IOMMU I managed
to corrupt a few super blocks this way because random data would be written then.

The block drivers have this pretty much all fixed these days, but in some other
areas (like network drivers) it looks much worse. So if your file system is
actually a network file system this might be a problem.

-Andi

  reply	other threads:[~2008-07-15 12:15 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-10 21:56 [SUGGESTION]: drop virtual merge accounting in I/O requests Mikulas Patocka
2008-07-10 21:56 ` Mikulas Patocka
2008-07-10 22:59 ` Julian Calaby
2008-07-10 22:59   ` Julian Calaby
2008-07-10 23:57   ` Mikulas Patocka
2008-07-10 23:57     ` Mikulas Patocka
2008-07-11  6:20 ` FUJITA Tomonori
2008-07-11  6:20   ` FUJITA Tomonori
2008-07-11 10:52   ` Mikulas Patocka
2008-07-11 10:52     ` Mikulas Patocka
2008-07-11 11:15     ` FUJITA Tomonori
2008-07-11 11:15       ` FUJITA Tomonori
2008-07-11 19:41       ` David Miller
2008-07-11 19:41         ` David Miller
2008-07-11 20:22         ` Mikulas Patocka
2008-07-11 20:22           ` Mikulas Patocka
2008-07-12 12:30 ` Andi Kleen
2008-07-12 12:30   ` Andi Kleen
2008-07-13 13:34   ` Mikulas Patocka
2008-07-13 13:34     ` Mikulas Patocka
2008-07-13 13:50     ` Andi Kleen
2008-07-13 13:50       ` Andi Kleen
2008-07-13 19:46       ` David Miller
2008-07-13 19:46         ` David Miller
2008-07-13 20:13         ` Andi Kleen
2008-07-13 20:13           ` Andi Kleen
2008-07-13 23:53           ` Mikulas Patocka
2008-07-13 23:53             ` Mikulas Patocka
2008-07-14  0:48             ` David Miller
2008-07-14  0:48               ` David Miller
2008-07-14 12:16               ` Mikulas Patocka
2008-07-14 12:16                 ` Mikulas Patocka
2008-07-14 12:28                 ` David Miller
2008-07-14 12:28                   ` David Miller
2008-07-14 14:03                   ` Mikulas Patocka
2008-07-14 14:03                     ` Mikulas Patocka
2008-07-14 21:37                     ` David Miller
2008-07-14 21:37                       ` David Miller
2008-07-14 23:16                       ` Mikulas Patocka
2008-07-14 23:16                         ` Mikulas Patocka
2008-07-15  1:31                         ` David Miller
2008-07-15  1:31                           ` David Miller
2008-07-15 22:32                           ` Mikulas Patocka
2008-07-15 22:32                             ` Mikulas Patocka
2008-07-15 22:37                             ` David Miller
2008-07-15 22:37                               ` David Miller
2008-07-15 22:59                               ` Mikulas Patocka
2008-07-15 22:59                                 ` Mikulas Patocka
2008-07-15  2:40                     ` FUJITA Tomonori
2008-07-15  2:40                       ` FUJITA Tomonori
2008-07-14  0:41           ` David Miller
2008-07-14  0:41             ` David Miller
2008-07-14  2:19             ` FUJITA Tomonori
2008-07-14  2:19               ` FUJITA Tomonori
2008-07-14  3:20               ` David Miller
2008-07-14  3:20                 ` David Miller
2008-07-14 17:45                 ` FUJITA Tomonori
2008-07-14 17:45                   ` FUJITA Tomonori
2008-07-14 21:26                   ` Mikulas Patocka
2008-07-14 21:26                     ` Mikulas Patocka
2008-07-15  2:40                     ` FUJITA Tomonori
2008-07-15  2:40                       ` FUJITA Tomonori
2008-07-15 12:09                       ` Mikulas Patocka
2008-07-15 12:09                         ` Mikulas Patocka
2008-07-15 12:15                         ` Andi Kleen [this message]
2008-07-15 12:15                           ` Andi Kleen
2008-07-15 13:16                           ` Mikulas Patocka
2008-07-15 13:16                             ` Mikulas Patocka
2008-07-15 14:06                             ` Andi Kleen
2008-07-15 14:06                               ` Andi Kleen
2008-07-15 12:19                         ` FUJITA Tomonori
2008-07-15 12:19                           ` FUJITA Tomonori
2008-07-16  3:10                   ` David Miller
2008-07-16  3:10                     ` David Miller
2008-07-16  4:38                     ` FUJITA Tomonori
2008-07-16  4:38                       ` FUJITA Tomonori

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=487C94CC.3090402@firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=davem@davemloft.net \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=sparclinux@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.