Re: hammer prune explanation

[Michael Neumann <mneumann@xxxxxxxx>]

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 
concept.
>     All it understands, really, are object id's (aka inode numbers) and
>     records.
>
>     The hammer utility on the other hand can actually scan the filesystem
>     hierarchy.
>
>     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.

Imagine:

  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
separate filesystems.

>     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:

  /a@12312323
  /a@12312323/x@...
  /b@43434343

Regards,

  Michael