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