On Jan 2, 2007, at 6:48 AM, Darren Reed wrote:
Darren J Moffat wrote:
...
Of course. I didn't mention it because I thought it was obvious
but this would NOT break the COW or the transactional integrity of
ZFS.
One of the possible ways that the to be bleached blocks are
dealt with in
David Bustos wrote:
Quoth Darren J Moffat on Thu, Dec 21, 2006 at 03:31:59PM +:
Pawel Jakub Dawidek wrote:
I like the idea, I really do, but it will be s expensive because of
ZFS' COW model. Not only file removal or truncation will call bleaching,
but every single file system
Darren J Moffat wrote:
...
Of course. I didn't mention it because I thought it was obvious but
this would NOT break the COW or the transactional integrity of ZFS.
One of the possible ways that the to be bleached blocks are dealt
with in the face of a crash is just like everything else -
Quoth Darren J Moffat on Thu, Dec 21, 2006 at 03:31:59PM +:
Pawel Jakub Dawidek wrote:
I like the idea, I really do, but it will be s expensive because of
ZFS' COW model. Not only file removal or truncation will call bleaching,
but every single file system modification... Heh, well, if
On Tue, 2006-12-26 at 13:59 -0500, Torrey McMahon wrote:
clearly you'd need to store the unbleached list persistently in the
pool.
Which could then be easily referenced to find all the blocks that were
recently deleted but not yet bleached? Is my paranoia running a bit too
high?
I
On Wed, Dec 27, 2006 at 08:45:23AM -0500, Bill Sommerfeld wrote:
I think your paranoia is indeed running a bit high if the alternative is
that some blocks escape bleaching forever when they were freed shortly
before a crash.
Lazy bg bleaching of freed blocks is not enough if you're really
Darren J Moffat wrote:
Pawel Jakub Dawidek wrote:
I like the idea, I really do, but it will be s expensive because of
ZFS' COW model. Not only file removal or truncation will call bleaching,
but every single file system modification... Heh, well, if privacy of
your data is important
On Tue, 2006-12-26 at 14:01 +0300, Victor Latushkin wrote:
What happens if fatal failure occurs after the txg which frees blocks
have been written but before before txg doing bleaching will be
started/completed?
clearly you'd need to store the unbleached list persistently in the
pool.
Bill Sommerfeld wrote:
On Tue, 2006-12-26 at 14:01 +0300, Victor Latushkin wrote:
What happens if fatal failure occurs after the txg which frees blocks
have been written but before before txg doing bleaching will be
started/completed?
clearly you'd need to store the unbleached list
Pawel Jakub Dawidek wrote:
I like the idea, I really do, but it will be s expensive because of
ZFS' COW model. Not only file removal or truncation will call bleaching,
but every single file system modification... Heh, well, if privacy of
your data is important enough, you probably don't care
Frank Hofmann wrote:
And this kind of deep bleaching would also break if you use snapshots
- how do you reliably bleach if you need to keep the all of the old data
around ? You only could do so once the last snapshot is gone. Kind of
defeating the idea - automatic but delayed indefinitely till
On Thu, Dec 21, 2006 at 03:31:59PM +, Darren J Moffat wrote:
Pawel Jakub Dawidek wrote:
I like the idea, I really do, but it will be s expensive because of
ZFS' COW model. Not only file removal or truncation will call bleaching,
but every single file system modification... Heh, well,
Nicolas Williams wrote:
James makes a good argument that this scheme won't suffice for customers
who need that level of assurance. I'm inclined to agree. For customers
who don't need that level of assurance then encryption ought to suffice.
Has anyone other than me actually read the current
On Thu, Dec 21, 2006 at 03:47:07PM +, Darren J Moffat wrote:
Nicolas Williams wrote:
James makes a good argument that this scheme won't suffice for customers
who need that level of assurance. I'm inclined to agree. For customers
who don't need that level of assurance then encryption
One other area where is is useful is when you are in a jurisdiction
where a court order may require you to produce your encryption keys -
yes such jurisdictions exist and I don't want to debate the human
rights angle or social engineering aspects of this just state that it
exists.
For such
Darren J Moffat wrote:
One other area where is is useful is when you are in a jurisdiction
where a court order may require you to produce your encryption keys -
yes such jurisdictions exist and I don't want to debate the human
rights angle or social engineering aspects of this just state that
On Tue, Dec 19, 2006 at 02:04:37PM +, Darren J Moffat wrote:
In case it wasn't clear I am NOT proposing a UI like this:
$ zfs bleach ~/Documents/company-finance.odp
Instead ~/Documents or ~ would be a ZFS file system with a policy set
something like this:
# zfs set erase=file:zero
Pawel Jakub Dawidek writes:
The goal is the same as the goal for things like compression in ZFS, no
application change it is free for the applications.
I like the idea, I really do, but it will be s expensive because of
ZFS' COW model. Not only file removal or truncation will call
On Wed, 20 Dec 2006, Pawel Jakub Dawidek wrote:
On Tue, Dec 19, 2006 at 02:04:37PM +, Darren J Moffat wrote:
In case it wasn't clear I am NOT proposing a UI like this:
$ zfs bleach ~/Documents/company-finance.odp
Instead ~/Documents or ~ would be a ZFS file system with a policy set
Nicolas Williams wrote:
On Mon, Dec 18, 2006 at 05:44:08PM -0500, Jeffrey Hutzelman wrote:
On Monday, December 18, 2006 11:32:37 AM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
I'd say go for both, (a) and (b). Of course, (b) may not be easy to
implement.
Another option would be to
Jeffrey Hutzelman wrote:
On Monday, December 18, 2006 05:51:14 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
On Mon, Dec 18, 2006 at 06:46:09PM -0500, Jeffrey Hutzelman wrote:
On Monday, December 18, 2006 05:16:28 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
Or an
In case it wasn't clear I am NOT proposing a UI like this:
$ zfs bleach ~/Documents/company-finance.odp
Instead ~/Documents or ~ would be a ZFS file system with a policy set
something like this:
# zfs set erase=file:zero
Or maybe more like this:
# zfs create -o erase=file -o
On Tue, Dec 19, 2006 at 02:04:37PM +, Darren J Moffat wrote:
In case it wasn't clear I am NOT proposing a UI like this:
$ zfs bleach ~/Documents/company-finance.odp
Instead ~/Documents or ~ would be a ZFS file system with a policy set
something like this:
# zfs set erase=file:zero
Nicolas Williams wrote:
On Tue, Dec 19, 2006 at 02:04:37PM +, Darren J Moffat wrote:
In case it wasn't clear I am NOT proposing a UI like this:
$ zfs bleach ~/Documents/company-finance.odp
Instead ~/Documents or ~ would be a ZFS file system with a policy set
something like this:
# zfs
On Tue, Dec 19, 2006 at 04:37:36PM +, Darren J Moffat wrote:
I think you are saying it should have INHERITY set to YES and EDIT set
to NO. We don't currently have any properties like that but crypto will
need this as well - for a very similar reason with clones.
What I mean is that if
On Tue, Dec 19, 2006 at 03:09:03PM -0500, Jeffrey Hutzelman wrote:
On Tuesday, December 19, 2006 01:54:56 PM + Darren J Moffat
[EMAIL PROTECTED] wrote:
While I think having this in the VOP/FOP layer is interesting it isn't
the problem I was trying to solve and to be completely
On 12/18/06, Darren J Moffat [EMAIL PROTECTED] wrote:
[ This is for discussion, it doesn't mean I'm actively working on this
functionality at this time or that I might do so in the future. ]
When we get crypto support one way to do secure delete is to destroy
the key. This is usually a
IMO:
- The hardest problem in the case of bleaching individual files or
datasets is dealing with snapshots/clones:
- blocks not shared with parent/child snapshots can be bleached with
little trouble, of course.
- But what about shared blocks?
IMO we have two options:
On Mon, Dec 18, 2006 at 05:44:08PM -0500, Jeffrey Hutzelman wrote:
On Monday, December 18, 2006 11:32:37 AM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
I'd say go for both, (a) and (b). Of course, (b) may not be easy to
implement.
Another option would be to warn the user and set
On Mon, Dec 18, 2006 at 06:46:09PM -0500, Jeffrey Hutzelman wrote:
On Monday, December 18, 2006 05:16:28 PM -0600 Nicolas Williams
[EMAIL PROTECTED] wrote:
Or an iovec-style specification. But really, how often will one prefer
this to truncate-and-bleach? Also, the to-be-bleached
30 matches
Mail list logo
