linux-ext4 - Re: Data integrity built into the storage stack

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: <4A9D1F0F.9050802@hp.com>
Date:	Tue, 01 Sep 2009 09:18:07 -0400
From:	jim owens <jowens@...com>
To:	Pavel Machek <pavel@....cz>
CC:	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Greg Freemyer <greg.freemyer@...il.com>,
	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-ext4@...r.kernel.org
Subject: Re: Data integrity built into the storage stack

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
--
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