HAMMER2 + new PFS + reboot
The situation is like this: I create PFS on mounted HAMMER2 (tryed with mounted LOCAL or ROOT), copy several files there and turn off the machine by `shutdown -p now'.
Here is crash #4 (four because of previuos 0-3 are the same - I made about ten PFSes:) )
#1 Updated by dillon about 1 month ago
- Status changed from New to In Progress
- Assignee set to dillon
I fixed a number of PFS related bugs this afternoon where crashes could occur on (A) umount and (B) if you attempt to mount device@LABEL where LABEL does not exist. Update and keep watch. Multiple PFS mounting and unmounting has not been heavily tested yet and from your bug report there could be more issues. In particular, I have not come across the problem reported in your core.txt.4 where multiple chains are still active on the last umount... that's serious. Only the v-chain and the f-chain roots are supposed to still be active.
I will start testing with more PFS's. Definitely keep updating this bug with PFS-related issues you come across.
#2 Updated by yellowrabbit2010 about 1 month ago
Now that you said that I remember that among other things the vicious sequence had the form:
hammer2 pfs-create USR-SRC
hammer2 pfs-create USR-OBJ
mount @USR-SRC /mnt/tmp-a
mount @USR-OBJ /mnt/tmp-b
cpdup /usr/src/ /mnt/tmp-a/
umount /mnt/tmp-a; umount /mnt/tmp-b
#4 Updated by yellowrabbit2010 29 days ago
- File core.txt.1 added
after commit 6aaf5cb056c245e31c88b76173b180ac450e9a64.
The system works well, >10 PFSes, very many compilations and movements of a large number of small files, as well as huge QEMU images for 6 hours.
Occasionally (1 time in 4 minutes) LOST CHILD was observed.
Unfortunately, when the computer turned off, hammer2_pfs_memory_inc() happened again.
#6 Updated by yellowrabbit2010 29 days ago
after commit 28efb08b59554982eb3821fe0667704282992817.
I already have non-empty @USR-SRC & @USR-OBJ mounted, so I decided destroy them and run some tests with fresh created PFSes.
mount @USR-SRC tmp
cpdup -i0 tmp/ /usr/src
hammer2 pfs-delete USR-OBJ
I assumed the next step was to remove @USR-SRC, but did not have time to type the command completely as the machine started to write a dump. You can see it on photo :)
BTW USR-OBJ wasn't in fact destroyed, it is mounted fine after that.