0x0000000000000000 is not a valid transaction id. Not sure how it wound up in the snapshot list but that slave has not been synchronized from a master yet and until it is there is no real snapshot.
-Matt On Sat, Apr 8, 2017 at 9:55 AM, <[email protected]> wrote: > Hi, > > I have other information.. the behavior started to be 100% reproducible on > my machine: every time I added a file I found it in the past snapshot. But > it appeared after a delay, ranging from 1 to about 20 seconds! > > % hammer snapls /home/attic/ > Snapshots on /home/attic/ PFS#2 > Transaction ID Timestamp Note > 0x0000000000000000 2017-04-06 09:57:34 CEST - > > % pwd > /home/attic > > % touch a_new_file > % ls .@@0x0000000000000000 > disk_stats.txt > > The file isn't in the snapshot yet. But if a i keep repeating the ls > command after a few seconds I find it: > > % ls .@@0x0000000000000000 > a_new_file disk_stats.txt > > > Then I decided to run hammer cleanup: > > # hammer cleanup > [... Output snipped ...] > cleanup /home/attic - handle PFS#2 using /var/hammer/home/attic > snapshots - run > prune - run > rebalance - run.. > reblock - run.... > recopy - skip > [... Output snipped ...] > > Now I have a new snapshot but the old snapshot is gone: > > % hammer snapls /home/attic/ > Snapshots on /home/attic/ PFS#2 > Transaction ID Timestamp Note > 0x00000001186c2200 2017-04-08 18:25:50 CEST - > > This new snapshot doesn't exhibit the behavior described above: I can add > and delete files in the main directory and the snapshot doesn't change. > > Sadly, now I have no access to the old snapshot to further diagnose the > problem. I didn't think hammer cleanup would delete a snapshot from two > days ago. > > > Kind regards, > Andrea > > > >
