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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ