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 ar
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 st
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 e
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 curren
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 indefinit
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
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 encryptio
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, w
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=fil
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 polic
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
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
> 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 honest I'm rea
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
On Tuesday, December 19, 2006 01:54:56 PM + Darren J Moffat
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 honest I'm really
> not interested in solving this outside of ZFS - why make it easy for
> pe
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 erasemethod=zero
Jeffrey Hutzelman wrote:
>
>
> On Monday, December 18, 2006 05:51:14 PM -0600 Nicolas Williams
> 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
>>> wrote:
>>>
>>> > Or an iovec-style sp
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
>> 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
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 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=fil
On Monday, December 18, 2006 05:51:14 PM -0600 Nicolas Williams
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
>> wrote:
>>
>> > Or an iovec-style specification. But really, how often will o
On Monday, December 18, 2006 05:16:28 PM -0600 Nicolas Williams
wrote:
> Or an iovec-style specification. But really, how often will one prefer
> this to truncate-and-bleach? Also, the to-be-bleached octet ranges may
> not be meaningful in snapshots/clones. Hmmm. That convinces me:
> trunc
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
> wrote:
>
> >Or an iovec-style specification. But really, how often will one prefer
> >this to truncate-and-bleach? Also, the to-be-bleached octet ranges
On Mon, Dec 18, 2006 at 05:16:28PM -0600, Nicolas Williams wrote:
> On Mon, Dec 18, 2006 at 05:44:08PM -0500, Jeffrey Hutzelman wrote:
BTW, Jeff's posts to zfs-discuss are being rejected with this message:
You are not allowed to post to this mailing list, and your message
has been automatic
On Monday, December 18, 2006 11:32:37 AM -0600 Nicolas Williams
wrote:
> 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 tr
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
> 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 a flag on
[ 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 much simpler and faster task than erasing
and overwriting
On Mon, Dec 18, 2006 at 11:32:37AM -0600, Nicolas Williams wrote:
>The new system call should either appear to truncate the file or to
>overwrite it with zeros. The latter would allow for bleaching some
>byte ranges, rather than the whole file (ZFS complexity: first COW
>the non-bl
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 12/18/06, Darren J Moffat 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 much simple
29 matches
Mail list logo
