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 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:
> truncate-and-bleach or bleach-and-zero, but not bleach individual
octet
> ranges.
Well, consider a file with some structure, like a berkeley db database.
The application may well want to bleach each record as it is deleted.
My point is those byte ranges might differe from one version of that
file to another.
That byte range contains the data the application is trying to bleach in
any version of the file which contains the affected block(s). Obviously
if the file has been modified and the data moved to someplace else, then
your bleach won't affect the version(s) of the file before the change.
But then, there's only so much you can do.
I explicitly do NOT want the applications involved in this, the whole
point of my proposal being the way it was is that it works equally for
all applications and no application code needs to or can be changed to
change this behaviour. Just like doing crypto "in" the filesystem vs
doing it at the application layer.
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
