sys/vfs/hammer: Check root voume# is 0 on mount(2) We could check this in addition to the existing conditional to know the volume is the root volume. /sbin/hammer and /sbin/mount_hammer do this, so why not. If failed here, the volume which has just been inserted to the rbtree (and other volumes already inserted) are going to be removed by hammer_free_hmp().
hammer - HAMMER Version 7 * Add support for version 7 which changes the CRC mechanic from the old slow CRC code to the faster ISCSI CRC code. We don't use the CRC instruction yet but ths base ISCSI CRC from FreeBSD is 6x faster than the CRC code we were using before. * Change newfs_hammer default to version 7 (for master).
sbin/hammer: Add hammer strip command This command is inspired by hammer recover command, and does opposite of what recover command does. This command zero clears zone-8(B-Tree) big-blocks, zone-9(meta) big-blocks, and then the whole volume header, except that volume signature field is overwritten with "STRIPPED" instead of zeros. After running, a filesystem is no longer mountable or recoverable with hammer recover command. This command is also fast as it only zero clears good enough ondisk data to make it unmountable and unrecoverable. Keep in mind that this command does _not_ zero clear user data. Users would normally use a software designed to completely shred a filesystem. This command is not designed to shred a filesystem. The name "strip" gives better idea of what it really does than using "shred"/etc. -- example # newfs_hammer -L TEST /dev/da1 /dev/da2 /dev/da3 > /dev/null # mount_hammer /dev/da1:/dev/da2:/dev/da3 /HAMMER # cd /HAMMER # dd if=/dev/urandom of=./out bs=1M count=120000 120000+0 records in 120000+0 records out 125829120000 bytes transferred in 1766.417077 secs (71234094 bytes/sec) # cd # umount /HAMMER # hammer -f /dev/da1:/dev/da2:/dev/da3 strip You have requested that HAMMER filesystem (TEST) be stripped Do you really want to do this? [y/n] y Stripping HAMMER filesystem (TEST) in 5 4 3 2 1.. starting destruction pass 8000000021000000 9000000021800000 800000019c000000 800000030c000000 800000047e000000 80000005f7000000 8000000767000000 80000008d8000000 8000000a51800000 8000000bc5000000 8000000d37800000 8000000ead000000 800000101e800000 8000001193000000 8000001304000000 8000001478800000 80000015ee000000 8000001760800000 80000018d1800000 8000001a47000000 8000001bb6000000 801000013c000000 /dev/da1 /dev/da2 /dev/da3 # mount_hammer /dev/da1:/dev/da2:/dev/da3 /HAMMER mount: Invalid argument mount_hammer: /dev/da1: Invalid volume signature 4445505049525453
sys/vfs/hammer: Rename HAMMER_STRUCTURE_XXX to HAMMER_IOTYPE_XXX enum hammer_io_type has existed since 2007, but the name of each element HAMMER_STRUCTURE_XXX doesn't clearly show the purpose of this enum. It should be HAMMER_IOTYPE_XXX. This isn't for ondisk structures, so it doesn't affect userspace.
sys/vfs/hammer: Fix zone/iotype/iostring conversion This isn't explcitly mentioned in documentations/comments/etc, but HAMMER_STRUCTURE_META_BUFFER is mapped to zone-{2,4,8,9}. Avoid using default: case when we know that. hammer_io_read() needs a case for zone-2 with "buffer" string. This avoids using a wrong message "meta?" for zone-2.
sys/vfs/hammer: Rename ondisk vol_name to vol_label Ondisk volume header having a field named vol_name for a label (not a block device path) is confusing, especially when inmemory volume structure has vol_name for a block device but not a label. There is even a kprintf message wrongly using ondisk vol_name as a block device path, as well as some comments saying vol_name is a filesystem label but not a path, which implies the name was misleading. This commit changes ondisk vol_name to vol_label. This commit also changes vol_name in struct hammer_ioc_info to vol_label. Outbox userspace programs using these two will see compile error after this commit (which I doubt there is any...). This commit doesn't break binaries. Note that vol_name in struct libhammer_fsinfo is unchanged.