On Tue, 19 Dec 2006, Darren J Moffat wrote:
Frank Hofmann wrote:
On the technical side, I don't think a new VOP will be needed. This could
easily be done in VOP_SPACE together with a new per-fs property - bleach
new block when it's allocated (aka VOP_SPACE directly, or in a backend also
called e.g. on allocating writes / filling holes), bleach existing block
when VOP_SPACE is used to "stamp a hole" into a file, aka a request is made
to bleach the blocks of an existing file.
I.e. make the implementation behind ftruncate()/posix_fallocate() do the
per-file bleaching if so desired. And that implementation is VOP_SPACE.
That isn't solving the problem though, it solves a different problem.
Well, the thread has taken lots of turns already; the "erase just a file"
task has been mentioned, and someone threw the idea of "VOP_BLEACH" in.
The problem that I want to be solved is that as files/datasets/pools are
deleted (not as they are allocated) they are bleached. In the cases there
VOP_SPACE() does truncation (free) as well as growth (alloc).
would not be a call to posix_fallocate() or ftruncate(), instead an unlink(2)
or a zfs destory or zpool destroy. Also on hotsparing in a disk - if the old
disk can still be written to in some way we should do our best to bleach it.
Since VOP_*() requires a filesystem (with "/" specifying "all of this
fs"), per-zvol or per-vdev "bleaching" needs a different implementation
vehicle, that's clear, as you don't have any handle then that you could
call it with.
I wouldn't just brush the VOP_*() approach aside. The world isn't pure ZFS
there's more to it, whether you wish otherwise or no ...
FrankH.
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
