From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: folkert <folkert@vanheusden.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>, linux-ext4@vger.kernel.org
Subject: Re: checksums
Date: Tue, 14 May 2013 12:21:43 -0700 [thread overview]
Message-ID: <20130514192143.GA6086@blackbox.djwong.org> (raw)
In-Reply-To: <20130514185754.GF2041@belle.intranet.vanheusden.com>
On Tue, May 14, 2013 at 08:57:54PM +0200, folkert wrote:
> > > Ok. But that would only when the filesystem is not mounted.
> > > Maybe some on-line functionality for doing so would be nice. I'm not
> > > totally aware of the filesystem structures in memory/on disk, but
> > > reading meta-data from disk which has changes pending in memory/in the
> > > journal would give at worst a verify of old(er) data. I don't think this
> > > (checking occasional old data) is a bad thing - scrubbing a
> > > raid-device/disk doesn't give you the situation for the whole disk(s) in
> > > 1 (!) point at time either. If that would be required, then the user
> > > could still unmount the filesystem and do a check.
> >
> > Well... if you ran filefrag -v on every file on the disk and read all the
> > xattrs, you'd scrub nearly all the metadata. The only things you'd miss are
> > unallocated parts of the disk, most of which e2fsck also skips.
>
> Yes but that is, imho, a bit dirty method.
> Because I assume the result will be a message in dmesg and the
> filesystem being remounted r/o?
> I think it would be better if a nice message on the user's terminal and
> an exit code.
You should see "I/O Error" (or whatever -EIO becomes in the message catalog) on
the terminal running filefrag if you hit a checksum error, in addition to a
complaint in dmesg and a ro fs.
> > > > That's not currently on the development roadmap; I could imagine
> > > > someone deciding to design an extension to ext4 that would do this
> > > > probably by storing the checksums in the indirect blocks, but no one
> > > > is currently working on it.
> >
> > sha256sum < file > file.sha256 ? :D
>
> Then you would need to read the whole file. I think it would be better
> to have this on e.g. block-level. 4KB so CRC32 suffices?
block or bigalloc-cluster level, I suppose.
--D
>
> > (If only there was disk space and brain-time to do something where you could
> > *reconstruct* data.)
>
> ah yes.
> These days everything is done by the gpu, maybe it can help with that :)
>
>
> Folkert van Heusden
>
> --
> www.vanheusden.com/multitail - multitail is tail on steroids. multiple
> windows, filtering, coloring, anything you can think of
> ----------------------------------------------------------------------
> Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
prev parent reply other threads:[~2013-05-14 19:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-14 9:14 checksums folkert
2013-05-14 13:18 ` checksums Theodore Ts'o
2013-05-14 14:40 ` checksums folkert
2013-05-14 18:09 ` checksums Darrick J. Wong
2013-05-14 18:57 ` checksums folkert
2013-05-14 19:21 ` Darrick J. Wong [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130514192143.GA6086@blackbox.djwong.org \
--to=darrick.wong@oracle.com \
--cc=folkert@vanheusden.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).