From: Joe Peterson <lavajoe@gentoo.org>
To: Josef Bacik <jbacik@redhat.com>
Cc: Zach Brown <zach.brown@oracle.com>, Mingming <cmm@us.ibm.com>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] COW and checksumming ioctls
Date: Fri, 20 Jun 2008 09:07:27 -0600 [thread overview]
Message-ID: <485BC7AF.6020708@gentoo.org> (raw)
In-Reply-To: <20080620135812.GB3224@unused.rdu.redhat.com>
Josef Bacik wrote:
> Database apps that do their own complicated stuff to make sure everything makes
> it to the disk properly who dont want the extra overhead of checksumming.
I do see the benefit of that, if indeed the DB does end-to-end checking.
Then again, I could almost see that perhaps making the setting based on
something at the subvolume level (not per-file level) might be even
better for that case.
> What if somebody logs in as root and does an rm -rf? I'm not thinking that
> running the command to disable checksumming on a file will be something that
> gets run often by accident, but even if it does the mantra of linux in general
> has never been "dont let users do something because some idiot could screw it
> all up."
Sure, that's true. I am not saying that we need to protect users from
themselves, as long as there is a way to clearly see what the settings
are (so a user/admin can verify the state, e.g.). I guess my main
concern would be if it is relatively easy for this to go completely
unnoticed. Also, would it be only root who could change such a setting?
> I don't really understand the above objection. Checksumming doesn't make
> everything magically protected, just makes it easier to catch when problems are
> happening. I don't see how having it off then turning it on would cause any
> sorts of issues.
Well, with checksumming on, there is continuous protection. And what I
mean by "protection" is peace-of-mind that the data integrity has been
checked (I don't necessarily mean protected from loss). For me,
*knowing* that the data is bad is the most important thing, so it does
not silently propagate to backups, etc.
So, if a file, say, is "protected" by checksumming as it gets read,
changed, etc., there is a continuity of protection, and the user can
have confidence that the data read is the same as the data written.
On the other hand, if one turns off checksumming, there is then a break
in that continuity, so any further reads or writes will not be be
checked. Even if the file is not written while not having checksumming
enabled, but then it is re-enabled, now there is no way to know that the
file's contents are the same as what they were before checksumming was
turned off - that confidence is lost.
-Joe
next prev parent reply other threads:[~2008-06-20 15:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-20 0:26 [PATCH] COW and checksumming ioctls Mingming
2008-06-20 5:23 ` Zach Brown
2008-06-20 14:01 ` Joe Peterson
2008-06-20 13:58 ` Josef Bacik
2008-06-20 15:07 ` Joe Peterson [this message]
2008-06-20 16:37 ` Chris Mason
2008-06-21 6:07 ` Joe Peterson
2008-06-20 19:44 ` jim owens
2008-06-21 5:59 ` Joe Peterson
2008-06-21 7:27 ` Christoph Hellwig
2008-06-22 14:10 ` Chris Mason
2008-06-22 18:13 ` Joshua J. Berry
2008-06-30 18:38 ` Christoph Hellwig
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=485BC7AF.6020708@gentoo.org \
--to=lavajoe@gentoo.org \
--cc=cmm@us.ibm.com \
--cc=jbacik@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=zach.brown@oracle.com \
/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