Issue #2863 has been updated by tkusumi.
from a link in comment #4 ------------------------------------------------------------------- ressurected# dd if=/dev/zero of=test.img bs=1m count=15000 15000+0 records in 15000+0 records out 15728640000 bytes transferred in 299.641029 secs (52491610 bytes/sec) ressurected# vnconfig -c vn test.img vn4 ressurected# disklabel64 -w -r /dev/vn4s0 auto ressurected# disklabel64 -e /dev/vn4s0 ressurected# newfs_hammer -f -L TEST /dev/vn4s0a Volume 0 DEVICE /dev/vn4s0a size 14.65GB initialize freemap volume 0 initializing the undo map (504 MB) --------------------------------------------- 1 volume total size 14.65GB version 6 boot-area-size: 32.00MB memory-log-size: 32.00MB undo-buffer-size: 504.00MB total-pre-allocated: 0.51GB fsid: 44b3c7ea-9f56-11e5-a636-11feed02b918 NOTE: Please remember that you may have to manually set up a cron(8) job to prune and reblock the filesystem regularly. By default, the system automatically runs 'hammer cleanup' on a nightly basis. The periodic.conf(5) variable 'daily_clean_hammer_enable' can be unset to disable this. Also see 'man hammer' and 'man HAMMER' for more information. WARNING: HAMMER filesystems less than 50GB are not recommended! You may have to run 'hammer prune-everything' and 'hammer reblock' quite often, even if using a nohistory mount. ressurected# mount /dev/vn4s0a /mnt/ ressurected# cd /mnt/ ressurected# touch it ressurected# hammer snapq . ./@@0x0000000100008020 ressurected# touch seems ressurected# hammer snapq . ./@@0x0000000100008080 ressurected# touch to\ be\ working ressurected# hammer snapq . ./@@0x0000000100008120 ressurected# cd ressurected# umount /mnt/ ressurected# mount /dev/vn4s0a /mnt/ ressurected# cd /mnt/ ressurected# hammer snapq . ./@@0x0000000000000000 ressurected# touch no\ it\ does\ not ressurected# hammer snapq . ./@@0x0000000100010220 ressurected# hammer snapls . Snapshots on . PFS #0 Transaction ID Timestamp Note 0x0000000000000000 2015-12-10 19:17:09 MSK - 0x0000000100008020 2015-12-10 19:16:29 MSK - 0x0000000100008080 2015-12-10 19:16:35 MSK - 0x0000000100008120 2015-12-10 19:16:54 MSK - 0x0000000100010220 2015-12-10 19:17:23 MSK - ---------------------------------------- Bug #2863: HAMMER synch tid is zero http://bugs.dragonflybsd.org/issues/2863#change-12770 * Author: shamaz * Status: New * Priority: Normal * Assignee: * Category: * Target version: ---------------------------------------- Hello. This appears on DragonFlyBSD 4.2 (and maybe newer) if you try the following with HAMMER filesystem: 1) Create a new vnode device. # dd if=/dev/zero of=test.img bs=1m count=15000 # vnconfig -c vn test.img # disklabel64 -w -r vn4s0 auto # disklabel64 -e vn4s0 Add a line like "a: * 0 HAMMER" 2) Create a HAMMER filesystem: newfs_hammer -f -L TEST /dev/vn4s0a 3) Mount it: mount /dev/vn4s0a /mnt 4) Try to sync it: hammer synctid /mnt You will see zero sync tid (0x0000000000000000). If you try to set some debug-related sysctls, it will get you no info at all when syncing. Also hammer pfs-status /mnt will show that sync-end-tid does not increment in time as it should. I am not sure if it happens with any non-root hammer FS, or just with those based on vn pseudo disks. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
