Hammer filesystem removal of a file.

Rohit Menon rohit.forum33 at gmail.com
Wed Nov 26 04:22:27 PST 2014 

Hello Justin,

Tried your steps and that doesn't seems to work as well.
Though my main issue was a lack of space in another hard disk which seems
to have been solved I wanted to create a proper documentation on the steps
regarding this so I tested it with this hard disk.


On Sun, Nov 23, 2014 at 10:36 PM, Rohit Menon <rohit.forum33 at gmail.com>
wrote:

> 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/20141126/10bcc2b8/attachment-0003.htm>

More information about the Hammer mailing list