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 >
