Hammer filesystem removal of a file.

Rohit Menon rohit.forum33 at gmail.com
Sun Nov 23 09:06:28 PST 2014


Hello Justin,

Thanks for the work around.
I'll give it a shot and will get back with my findings.

On Sat, Nov 22, 2014 at 10:38 PM, Justin Sherrill <justin at shiningsilence.com
> wrote:

> 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/20141123/d552df7b/attachment-0009.html>


More information about the Hammer mailing list