Project

General

Profile

Bug #3057

HAMMER2 + new PFS + reboot

Added by yellowrabbit2010 about 1 month ago. Updated 25 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
09/17/2017
Due date:
% Done:

0%


Description

Hello,
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:) )

core.txt.4 (164 KB) yellowrabbit2010, 09/17/2017 04:24 PM

core.txt.1 (202 KB) yellowrabbit2010, 09/21/2017 04:22 PM

IMG_20170922_121343-min.jpg View (1.39 MB) yellowrabbit2010, 09/21/2017 07:43 PM

core.txt.2 (346 KB) yellowrabbit2010, 09/21/2017 07:44 PM

History

#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.

-Matt

#2 Updated by yellowrabbit2010 about 1 month ago

I will.

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
---
not `shutdown'

#3 Updated by yellowrabbit2010 about 1 month ago

not only `shutdown' :)

#4 Updated by yellowrabbit2010 29 days ago

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.

#5 Updated by dillon 29 days ago

Ah, nice catch. I believe I have fixed the panic and several other related issues. I was missing some cleanup code related to unmounted PFS's, and had a bug in other code related to hammer2_pfs_memory_inc() calls during unmount.

-Matt

#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.
---
umount /usr/src
umount /usr/obj
mount @USR-SRC tmp
cpdup -i0 tmp/ /usr/src
umount tmp
cd aux-hdd
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.

#7 Updated by yellowrabbit2010 25 days ago

  • Status changed from In Progress to Resolved

The above problems are not observed anymore

Also available in: Atom PDF