Bug #2347
openHammer PFSes destroy does not give back full space allocated to PFS
0%
Description
I was mirroring PFSes from 3.1 dev to slaves in 3.02 and I found that
the PFSes took more space on the 3.02 slave.
Investigating I found this strange thing
94 GB is allocated for this slave PFS. But when it is removed only 52
GB is freed :-(
dfly-bkpsrv2# hammer dedup /pfs/software
Dedup running
Dedup /pfs/software succeeded
Dedup ratio = 1.06
100 GB referenced
94 GB allocated
4339 KB skipped
429 CRC collisions
0 SHA collisions
1 bigblock underflows
0 new dedup records
0 new dedup bytes
dfly-bkpsrv2# df -h
Filesystem Size Used Avail Capacity Mounted on
ROOT 459G 354G 106G 77% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/serno/QM00001.s1a 756M 168M 527M 24% /boot
/pfs/@-1:00001 459G 354G 106G 77% /var
@-1:00002 459G 354G 106G 77% /tmp
/pfs/
/pfs/@-1:00003 459G 354G 106G 77% /usr
@-1:00004 459G 354G 106G 77% /home
/pfs/
/pfs/@-1:00005 459G 354G 106G 77% /usr/obj
@-1:00006 459G 354G 106G 77% /var/crash
/pfs/
/pfs/@-1:00007 459G 354G 106G 77% /var/tmp
@-1:00001 459G 302G 158G 66% /var
procfs 4.0K 4.0K 0B 100% /proc
dfly-bkpsrv2# ls
home software usr var
var.tmp vms2-lxc
mysql-baks tmp usr.obj var.crash vms1-lxc
dfly-bkpsrv2# hammer pfs-destroy /pfs/software
You have requested that PFS#11 () be destroyed
This will irrevocably destroy all data on this PFS!!!!!
Do you really want to do this? y
Destroying PFS #11 () in 5 4 3 2 1.. starting destruction pass
pfs-destroy of PFS#11 succeeded!
dfly-bkpsrv2# df -h
Filesystem Size Used Avail Capacity Mounted on
ROOT 459G 302G 158G 66% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/serno/QM00001.s1a 756M 168M 527M 24% /boot
/pfs/
/pfs/@-1:00002 459G 302G 158G 66% /tmp
@-1:00003 459G 302G 158G 66% /usr
/pfs/
/pfs/@-1:00004 459G 302G 158G 66% /home
@-1:00005 459G 302G 158G 66% /usr/obj
/pfs/
/pfs/@-1:00006 459G 302G 158G 66% /var/crash
@-1:00007 459G 302G 158G 66% /var/tmp
/pfs/
procfs 4.0K 4.0K 0B 100% /proc
Updated by sgeorge over 12 years ago
- Description updated (diff)
- Status changed from New to Feedback
- Priority changed from Normal to High
I wonder if this is a hardware trouble.
It now gives the error.
HAMMER recovery check seqno=8ca97e62
HAMMER recovery range 3000000006877528-3000000006892fa0
HAMMER recovery nexto 3000000006892fa0 endseqno=8ca98015
HAMMER recovery undo 3000000006877528-3000000006892fa0 (113272 bytes)(RW)
ad4: FAILURE - READ_DMA48 status=51<READY,DSC,ERROR> error=40<UNCORRECTABLE> LBA=483752928
HAMMER: UNDO record, cannot access buffer 2000003436e35ca8
HAMMER UNDO record at 3000000006891a30 failed
HAMMER recovery complete
Failed to recover HAMMER filesystem on mount