Hammer filesystem removal of a file.
Justin Sherrill
justin at shiningsilence.com
Sat Nov 22 09:08:57 PST 2014
>From man 8 hammer
prune softlink-dir
Prune the file system based on previously created snapshot
softlinks. Pruning is the act of deleting file system history.
The prune command will delete file system history such that the
file system state is retained for the given snapshots, and all
history after the latest snapshot. By setting the per PFS
parameter prune-min, history is guaranteed to be saved at least
this time interval. All other history is deleted.
If you set prune-min to 1 day, you are guaranteeing that at least 1 day of
history is saved.
Mounting nohistory means it does not create new historic information, but
it does not remove any existing data.
Also, df reports the overall space used for a Hammer volume every time.
That 63G reported for /Backup5/vm8 is the overall space used for data, not
the space of that mounted point. Hammer is only storing the changes to
data, not a copy of all the data itself from that point in time, so it's a
much smaller portion of the data.
Backup5 929G 63G 866G 7% /Backup5
/Backup5/pfs/@@-1:00001 929G 63G 866G 7% /Backup5/vms8
Here's my suggestion:
- Tell Hammer to stop taking snapshots in the config file, and to run
cleanup steps for as long as needed. Note that the period of 1 minute
means it won't start any of the cleanup processes within 1 minute of doing
it previously. Normally that's set to a day, since cleanup is done daily.
(cd /Backup5; hammer viconfig)
snapshots 0d 0d
prune 1m 0m
reblock 1m 0m
recopy 1m 0m
rebalance 1m 0m
- Use 'hammer snapls' and 'hammer snaprm' to remove any remaining snapshots.
- prune-everything.
Note that I haven't tried this myself.
On Fri, Nov 21, 2014 at 12:56 AM, Rohit Menon <rohit.forum33 at gmail.com>
wrote:
> Hello Matt,
>
> This was what I did to prune all snapshot data.
> However this part of history stays.
>
> This is my prune output
>
> dfly-bkpsrv1# hammer prune-everything /Backup5
> Prune /Backup5/: EVERYTHING
> Prune /Backup5/: objspace 8000000000000000:0000 7fffffffffffffff:ffff
> pfs_id 0
> Prune /Backup5/: prune_min is 1d/00:00:00
> Prune /Backup5/ succeeded
> Pruned 0/2065540 records (0 directory entries) and 0 bytes
>
> I modified the prune_min to 1 day since I could see that it wasnt exactly
> clearing history when set to default.
> The history data still stays
> ==============================================
> dfly-bkpsrv1# cd vms8/
> dfly-bkpsrv1# ll
> total 0
> dfly-bkpsrv1#
> =========================================================
> dfly-bkpsrv1# cd /Backup5/@@0x0000000108329000
> dfly-bkpsrv1# ll
> total 0
> drwxr-xr-x 1 root wheel 0 Nov 19 10:16 pfs
> drwxr-xr-x 1 root wheel 0 Nov 18 09:24 vms8
> dfly-bkpsrv1# cd vms8
> dfly-bkpsrv1# ls -l
> total 0
> drwxr-xr-x 1 root wheel 0 Nov 18 13:05 containers
> drwxr-xr-x 1 root wheel 0 Nov 18 14:29 env
> drwx------ 1 root wheel 0 Nov 18 13:05 lost+found
> drwxr-xr-x 1 root wheel 0 Nov 18 14:29 volumes
> dfly-bkpsrv1#
> =================================================
> And it is also using up space.
>
>
>
> Backup5 929G 63G 866G 7% /Backup5
> /Backup5/pfs/@@-1:00001 929G 63G 866G 7% /Backup5/vms8
>
> On Fri, Nov 21, 2014 at 10:59 AM, Matthew Dillon <dillon at backplane.com>
> wrote:
>
>> Rohit, there is a kitchen sink command to remove all history called
>> 'prune-everything'. Try running that on the target mount. 'hammer
>> prune-everything <blah>'.
>>
>> -Matt
>>
>> On Nov 20, 2014, at 8:11 PM, Rohit Menon <rohit.forum33 at gmail.com> wrote:
>>
>> Hello Justin,
>>
>> That makes things a bit more clear now.
>> Since its a read-only filesystem how am I supposed to do that
>> Also I tried mounting the filesystem nohistory the data is still shows
>> used up.
>> So does this mean I cannot remove this history.
>>
>> On Fri, Nov 21, 2014 at 6:20 AM, Justin Sherrill <
>> justin at shiningsilence.com> wrote:
>>
>>> What you are looking at is file history. Snapshots are moments in time
>>> of the entire volume. File history is a record of every change synced to
>>> disk. From hammer(5):
>>>
>>> If you've removed snapshots and pruned, it should have removed a great
>>> deal of the data. File history since the last snapshot is preserved,
>>> though. If you don't want any history kept, mount the Hammer volume
>>> nohistory. (see mount_hammer(8) )
>>>
>>> It will always be read-only because it's history; it already happened.
>>> If you want to modify the files, you will need to copy them out and then
>>> modify them on the "now" version of the filesystem.
>>>
>>>
>>> On Thu, Nov 20, 2014 at 7:28 AM, Rohit Menon <rohit.forum33 at gmail.com>
>>> wrote:
>>>
>>>> Hello Antonio,
>>>>
>>>> I have removed all the snapshots of the volume.
>>>> This has been done as documented that is hammer snapls and then
>>>> prune-everything.
>>>> I have noticed a peculiar behaviour though.
>>>> Im able to generate a transaction Id using hammer synctid
>>>> When I cd to the directory that is /Backup5/@@0x0000000108329000
>>>> Im able to see the data but cannot remove it as it is a read-only
>>>> filesystem.
>>>> I tried to null mount this and remove it to no avail.
>>>> Is there something Im still missing.
>>>>
>>>>
>>>> On Wed, Nov 19, 2014 at 5:17 PM, Antonio Huete Jiménez <
>>>> tuxillo at quantumachine.net> wrote:
>>>>
>>>>> Hi Rohit,
>>>>>
>>>>> There must be a snapshot referencing those files and that is the
>>>>> reason why they keep using the space.
>>>>> Check hammer(8) manpage on how to operate snapshots.
>>>>>
>>>>> Best regards,
>>>>> Antonio Huete
>>>>>
>>>>>
>>>>> Quoting Rohit Menon <rohit.forum33 at gmail.com>:
>>>>>
>>>>> Hello,
>>>>>>
>>>>>> Im a newbie to BSD as a whole.
>>>>>> Currently my company has a backup solution implemented in dragonfly
>>>>>> BSD
>>>>>> with hammer.
>>>>>> My question is simple, is there a specific way to remove a
>>>>>> file/folder in
>>>>>> hammer.
>>>>>>
>>>>>> The situation is like:
>>>>>>
>>>>>> I moved 65G data to one of my directoies /Backup under a specifc
>>>>>> directory.
>>>>>> When I removed it the the files and folders have been removed but the
>>>>>> occupied space remains.
>>>>>> I have done hammer cleanup and prune but to no avail.
>>>>>>
>>>>>>
>>>>>> Can you please guide me on where Im going wrong.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/hammer/attachments/20141122/322f55eb/attachment-0003.htm>
More information about the Hammer
mailing list