public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: jim owens <jowens@hp.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
	Greg Freemyer <greg.freemyer@gmail.com>,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-ext4@vger.kernel.org
Subject: Re: Data integrity built into the storage stack
Date: Tue, 01 Sep 2009 09:18:07 -0400	[thread overview]
Message-ID: <4A9D1F0F.9050802@hp.com> (raw)
In-Reply-To: <20090901124403.GC1371@ucw.cz>

Pavel Machek wrote:
> Hi!
> 
>> I do agree that we do have to be more prepared for collateral damage
>> scenarios.  As we discussed at LS we have 4KB drives coming out that can
>> invalidate previously acknowledged I/Os if it gets a subsequent write
>> failure on a sector.  And there's also the issue of fractured writes
> 
> Hmmm, future will be interesting.
> 
> 'ext3 expects disks to behave like disks from 1995' (alarming).

NO... stop saying "ext3".  All file systems expect that
what the disk tell us is the "sector size" (now know by
disk vendors as "block size") is "atomic".

The problem is not when they say 4096 bytes is my block.

The problem Martin is talking about is that since most
filesystems expect and work with legacy 512-byte-sectors,
the disk vendors report "512 is my block" and do the
merge themselves to their real 4096 byte physical sector.

This is not "bad drive vendor" either, it is the price
of progress while supporting legacy expectations.

jim

  reply	other threads:[~2009-09-01 13:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-29 21:23 Data integrity built into the storage stack [was: Re: [testcase] test your fs/storage stack (was Re: [patch] ext2/3: document conditions when reliable operation is possible)] Greg Freemyer
2009-08-30  0:35 ` Rob Landley
2009-09-01  5:19 ` Data integrity built into the storage stack Martin K. Petersen
2009-09-01 12:44   ` Pavel Machek
2009-09-01 13:18     ` jim owens [this message]
2009-09-01 13:37       ` Pavel Machek

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=4A9D1F0F.9050802@hp.com \
    --to=jowens@hp.com \
    --cc=greg.freemyer@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=pavel@ucw.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox