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 a flag on the shared block > which causes it to be bleached when the last reference goes away. Of > course, one still might want to give the user the option of forcing > immediate bleaching of the shared data.
Sure, but if I want something bleached I probably want it bleahced _now_, not who knows when. > > - Unlink is not the right operation to bleach on! > > > > That's because we don't have a fast dnode# -> path function (ncheck), > > and we don't have path info for the unlinked file in the snapshots > > and clones that share it (worse, they may have additional hard > > links). > > I'm not sure how this matters. It certainly is desirable to be able to set > policy which causes files to be automatically bleached on unlink (or, more > properly, when the link count goes to zero, modulo the complexity added by > clones and snapshots). But why set that per-file? Why not per-dataset/volume? "Bleach all blocks when they are freed" automatically means bleaching blocks when the lask reference is gone (as a result of an unlink of the last file that had some block, say). > > 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-bleached parts of blocks, then bleach the freed blocks). > > Perhaps the system call should act on a file descriptor, and specify a > range to be bleached, with a whence/start/len a la F_SETLK. This would > allow for bleaching byte ranges and also help with the vdev issue (one > might imagine an application which knows enough about what is on the device > to bleach only certain blocks). 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. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
