DragonFly users List (threaded) for 2008-05
DragonFly BSD
DragonFly users List (threaded) for 2008-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: hammer prune explanation


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sat, 10 May 2008 12:21:53 -0700 (PDT)

:Thanks a lot! Could this great explanation (or parts of it) go into the
:man-page? I think it's very helpful, especially the visualization.

    I am going to write up a whole paper on HAMMER.  It's almost time for
    me to sit down and do it.

:Is it possible to prune according to the filename? For example:
:
:   hammer prune /mnt/usr/obj from 2d everything
:   hammer prune /mnt/usr/src from 1d to 10d every 1d
:
:Don't know if it is possible to implement... but would avoid the need
:for separate filesystems.
:
:Regards,
:
:   Michael

    The filesystem supports pruning on an object-by-object basis, so
    it is possible to prune a single file.  The hammer utility does not
    currently have support for that, but it would not be difficult to
    add.  If you want a little side project, add it to the utility! 
    The core code that selects the object id range (aka inode numbers)
    is in /usr/src/sbin/hammer/cmd_prune.c line 74ish.

    What I would like to do is have a more sophisticated pruning capability
    in general, such as based on wildcarding and/or an inherited chflag
    flag, or perhaps be able to specify a pruning category selector on
    a file by file basis.  I don't know what the best approach is.

    Right now any serious HAMMER user need to set up at least a daily
    cron job to prune and reblock the filesystem.  I add a '-t timeout'
    feature to the HAMMER utility to make allow the operations to be
    set up in a cron job and keep the filesystem up to snuff over a long
    period of time.  So, e.g. you would have a nightly cron job that
    did this:

	# spend up to 5 minutes pruning the filesystem and another 
	# 5 minutes reblocking it, then stop.
	hammer -t 300 prune /myfilesystem; hammer -t 300 reblock /myfilesystem 

    Heh.  I just found a bug in the reblocking code, I got a CRC panic 
    because I didn't properly regenerate the CRC on the reblock.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]