[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: UFS2 metadata checksums
- To: Alexander Kabaev <kabaev_(_at_)_gmail_(_dot_)_com>
- Subject: Re: UFS2 metadata checksums
- From: Scott Burns <scott_(_at_)_bqinternet_(_dot_)_com>
- Date: Fri, 24 Apr 2009 02:45:29 -0400
- Cc: freebsd-fs_(_at_)_freebsd_(_dot_)_org
Alexander Kabaev wrote:
On Thu, 23 Apr 2009 06:54:51 -0400
Scott Burns <scott_(_at_)_bqinternet_(_dot_)_com> wrote:
I have spent some time writing a kernel module which calculates a
checksum of a UFS2 dinode structure and stores it in the reserved
space of the inode when writing it to disk. It is then verified when
the inode is read from disk. If the checksum verification fails, the
read returns an error (currently EIO).
I believe that protecting metadata integrity is important, especially
as storage capacity grows. Bitrot is a fact of life, and bad things
can happen if the kernel acts on a corrupted inode. Not only does
this module improve the stability of a server, but it also helps to
prevent additional damage to the filesystem that can be caused by
I'm aware that data integrity issues are addressed with ZFS, but
unfortunately ZFS is still not yet suitable for many workloads. I'm
also aware that integrity checking can be done by using GELI between
the filesystem and the disk, but at a noticeable cost in performance
and space utilization. The method this module uses is fast and does
not use any additional space. Most importantly, it builds on mature
code that has worked well for decades.
Before I spend much more time on it, I have some questions:
1) Has anyone else done any work in this area?
2) Is there a demand for this in FreeBSD?
This is actually something I would love to have in the base system,
but inodes are not the only structures that need the integrity
protection. Pretty much every other metadata block, from cylinder group
blocks to indirect blocks for files need similar protection for
this to be of real use.
As long as there is some interest in this kind of functionality, I will
continue working on it. The next step is to protect metadata structures
beyond inodes. I am hoping to have some results to post in the next few
BQ Internet Corporation
freebsd-fs_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-fs-unsubscribe_(_at_)_freebsd_(_dot_)_org"
Visit your host, monkey.org