Re: [Lsf-pc] [LSF/MM TOPIC] end-to-end data and metadata corruption detection
James Bottomley <James.Bottomley <at> HansenPartnership.com>
2012-02-01 16:52:55 GMT
On Wed, 2012-02-01 at 11:45 -0500, Chris Mason wrote:
> On Tue, Jan 31, 2012 at 11:28:26AM -0800, Gregory Farnum wrote:
> > On Tue, Jan 31, 2012 at 11:22 AM, Bernd Schubert
> > <bernd.schubert <at> itwm.fraunhofer.de> wrote:
> > > I guess we should talk to developers of other parallel file systems and see
> > > what they think about it. I think cephfs already uses data integrity
> > > provided by btrfs, although I'm not entirely sure and need to check the
> > > code. As I said before, Lustre does network checksums already and *might* be
> > > interested.
> >
> > Actually, right now Ceph doesn't check btrfs' data integrity
> > information, but since Ceph doesn't have any data-at-rest integrity
> > verification it relies on btrfs if you want that. Integrating
> > integrity verification throughout the system is on our long-term to-do
> > list.
> > We too will be said if using a kernel-level integrity system requires
> > using DIO, although we could probably work out a way to do
> > "translation" between our own integrity checksums and the
> > btrfs-generated ones if we have to (thanks to replication).
>
> DIO isn't really required, but doing this without synchronous writes
> will get painful in a hurry. There's nothing wrong with letting the
> data sit in the page cache after the IO is done though.
I broadly agree with this, but even if you do sync writes and cache read
only copies, we still have the problem of how we do the read side
verification of DIX. In theory, when you read, you could either get the
cached copy or an actual read (which will supply protection
information), so for the cached copy we need to return cached protection
information implying that we need some way of actually caching it.
(Continue reading)
> tracehook requires: > - task_pt_regs() in asm/processor.h or asm/ptrace.h > - arch_has_single_step() if there is hardware single-step support > - arch_has_block_step() if there is hardware block-step support > - asm/syscall.h supplying asm-generic/syscall.h interface > - linux/regset.h user_regset interfaces > - CORE_DUMP_USE_REGSET #define'd in linux/elf.h > -TIF_SYSCALL_TRACE calls tracehook_report_syscall_{entry,exit} > - TIF_NOTIFY_RESUME calls tracehook_notify_resume() > - signal delivery calls tracehook_signal_handler() Okay, that's a bit fuzzier than I expected. I suppose the archs implement some of that in another way currently? >>> Maybe not all archs, but at least some more. That way, every time someone >>> adds something tracehook specific, more archs support it. > > Well the other arch I want this on specifically for my purposes is > arm, but someone recently posted a partial asm/syscall.h for arm, but > I didn't see that one go anywhere just yet. (I know syscall_get_nr
RSS Feed