linux-kernel - 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: <yq1hbvntf62.fsf@sermon.lab.mkp.net>
Date:	Tue, 01 Sep 2009 01:19:49 -0400
From:	"Martin K. Petersen" <martin.petersen@...cle.com>
To:	Greg Freemyer <greg.freemyer@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-ext4@...r.kernel.org
Subject: Re: Data integrity built into the storage stack

>>>>> "Greg" == Greg Freemyer <greg.freemyer@...il.com> writes:

Greg> We already have the scsi data integrity patches that went in last
Greg> winter and I believe fit into the storage stack below the
Greg> filesystem layer.

The filesystems can actually use it.  It's exposed at the bio level.

Greg> I do believe there is a patch floating around for device mapper to
Greg> add some integrity capability.

The patch is in mainline.  It allows passthrough so the filesystems can
access the integrity features.  But DM itself doesn't use any of them,
it merely acts as a conduit.

DIF is inherently tied to storage device's logical blocks.  These are
likely to be smaller than the blocks we're interested in protecting.
However, you could conceivably use the application tag space to add a
checksum with filesystem or MD/DM blocking size granularity.  All the
hooks are there.

The application tag space is pretty much only available on disk
drives--array vendors use it for internal purposes.  But in the MD/DM
case we're likely to run on raw disk so that's probably ok.

That said, I really think btrfs is the right answer to many of the
concerns raised in this thread.  Everything is properly checksummed and
can be verified at read time.

The strength of DIX/DIF is that we can detect corruption at write time
while we still have the buffer we care about write sitting in memory.

So btrfs and DIX/DIF go hand in hand as far as I'm concerned.  They
solve different problems but both are squarely aimed at preventing
silent data corruption.

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
when talking to disk arrays.  That's really what my I/O topology changes
were all about: Correctness.  The fact that they may increase
performance is nice but that was not the main motivator.

-- 
Martin K. Petersen	Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/