nohistory'd directories on Hammer

Matthew Dillon dillon at apollo.backplane.com
Sat Jul 12 18:28:08 PDT 2008


:Oh, if only it recovered just 50% of space what I have freed up (50% of
:the whole partition size and it is still reported full).
:
:This is a real gotcha as I cannot use the reblocker cause the FS is
:full but to get space I need the reblocker. :-)
:
:-- 
:Gergo Szakal MD <bastyaelvtars at gmail.com>
:University Of Szeged, HU
:Faculty Of General Medicine

    Yah, its a problem, though I think rm + pruning ought to work.  You
    shouldn't have to free up more then 100MB of space or so for the
    reblocker to work.

    The reason we need so much slop space is because the reblocker is
    basically reblocking from 8MB big-blocks to 8MB big-blocks, but it
    is doing it by scanning the B-Tree which might not reference elements
    in the same source big-block linearly.

    There is a solution, but it is a bit nasty... the reblocker would have
    to try to clean out whole big-blocks at a time, which would mean scanning
    the B-Tree finding all the fragments that allocated out of those
    big-blocks.  If it did that the slop requirement would only be
    8x4 = 32MB of disk space free.  It's fairly easy to code up, but the
    algorithm is horribly inefficient.

    Maybe we also a 'hammer rm' command which also prunes the same files
    being removed, so you don't have to run the pruner on the whole
    filesystem.  I am a bit hesitant to provide workarounds to the
    history retention because the whole point of having it is to be able
    to recover from mistakes (amoung many other points).

    I'm open to suggestions.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>





More information about the Users mailing list