DragonFly users List (threaded) for 2008-05
Re: hammer prune explanation
Matthew Dillon wrote:
> :Yeah, I was thinking about wildcarding as well.
> :But is it possible to implement it within cmd_prune.c, or do I have to
> :modify the ioctl kernel code? If done in cmd_prune.c, I somehow have to
> :iterate over all deleted files and call the prune command for it.
> :I thought, it's easier to introduce a check in the kernel, whether the
> :file that should be pruned matches a given pattern. Doesn't sound very
> :hard to do, if it is easy to get the pathname for a given inode.
> :Are you thinking about something like the archive flag?
> I think it is probably best to implement that level of sophistication
> in the utility rather then in the kernel. The pruning ioctl code
> has no concept of files or directories... literally it has no
> All it understands, really, are object id's (aka inode numbers) and
> The hammer utility on the other hand can actually scan the filesystem
> Locating wholely deleted files and directories is not hard to do.
> As-of queries can be used to access earlier versions of a directory.
Hm, how would that work, if I want it to behave like the prune command?
I'd need to traverse a lot of filesystem trees, to just determine which
files were deleted.
compare /mnt with /mnt@1-hour-ago and prune deleted files.
compare /mnt@1-hour-ago with /mnt@2-hours-ago ...
I wouldn't find files that were deleted in between 1-hour-ago and
2-hours-ago. To make it work, I'd need to compare the filesystem trees
of every possible timestamp.
It's probably easier, and more efficient, to have
> We might want to add some kernel support to make it more efficient,
> for example to make it possible for the hammer utility to have
> visibility into all deleted directory entries. It could use that
> visbility to do as-of accesses and through that mechanic would thus
> have visibility into all deleted files and directories.
Does this mean, I'd see files like: