Unmounting a busy BFS image results in a continuable KDL (block_cache still has partial slabs)

[Giova84]

hrev50382 but I notice this behaviour since a long time, maybe is similar to ticket:6683.

Well, on my system I have a secondary BFS disk but this bug doesn't occurs when I unmount this phisical disk, and not even occurs as described in ticket:6683, because in my case this issue occurs just with a different way/disks: I use to backup my data by mounting a VHD file formatted as BFS: I mount this VHD file as:

diskimage register "$VHDFILE"
device=$(diskimage register "$VHDFILE")
disk=$(echo $device | cut -d\" -f2)
cd /
mkdir /HaikuBK
mount $disk /HaikuBK

and after that i saved my data I just unmount this disk by:

unmount /HaikuBK

But immediately after the unmounting, Haiku will drop in a KDL (from which, however, I can exit by the "es" command) and this KDL, luckily, doesn't cause any corruption on such disk.

[Giova84]

Update: now, instead, to mount and unmount such disk I simply use the mountvolume cli utility. However this bug still occurs; however today I was able to take a pair of picture from the KDL: pics attached.

[Giova84]

Sorry, this ticket seems a dup of ticket:10061

[Giova84]

I noticed a thing which is able to avoid this KDL: I will attempt to give a comprehensive description:

As I've said I use this disk to backup my data, and obviously i wait that all data is written to the disk, before to do the unmounting of the disk: well, I noticed that also for some minutes after the copy, the HDD LED on my computer's case, still indicate an HDD activity: but if unmount the disk in this situation, I don't see the classic alert window which told me that the disk is busy (and usually this window offers "force unmount"): well, if I wait until the HDD LED will turn off, I can umount the disk without see the KDL.

[axeld]

It's indeed a duplicate. However, it since you have provided a bit more info here that might allow reproducing the issue, I'm closing the other ticket instead.

[axeld]

(In #10061) Duplicate of #12847 which contains more useful information on how to possibly reproduce the issue.

[Giova84]

Since i switched to hrev51089, if before to unmount the disk i run the sync command, such KDL seems that no longer occurs. I'm quite sure That I tried the sync command in past, but still with the described KDL. Please leave this open ticket: I do daily backups and I will give you to a better confirm.

P.S: When i switched to hrev51089 I was no longer able to backup files using rsync (i got a lot of "file has vanished" warnings), but with hrev51094 everything is fine again :-)

[Giova84]

Replying to Giova84:

I noticed that also for some minutes after the copy, the HDD LED on my computer's case, still indicate an HDD activity: but if unmount the disk in this situation, I don't see the classic alert window which told me that the disk is busy (and usually this window offers "force unmount"): well, if I wait until the HDD LED will turn off, I can umount the disk without see the KDL.

This defenitely works - at least for me - to avoid the KDL. The last night I hit again the KDL after unmounting the disk: I didn't wait some minutes for unmount the disk (the HDD led was showing an activity of the disk). Today, after the backup, i went away for about five minutes and when I back I unmounted the disk without the KDL (the HDD led wasn't active).

In facts when I started to used the sync command I waited some minutes before to unmount the disk.

[diver]

Still here in hrev51983.

[ahwayakchih]

Unmount BFS image KDL

[ahwayakchih]

Still happening on Haiku x86_64 at hrev53144 running inside QEMU/KVM (for more info check description in #14466).

[ahwayakchih]

Another one, from latest hrev

[diver]

Still here in hrev53200.

[luroh]

hrev53269: Possibly gone, or at least harder for me to reproduce since around hrev53241 or so. Diver?

[diver]

It doesn't seem to crash but mounting another bfs image in already mounted one creates all sorts of issues.

[vidrep]

I just had this crash today, after installing a raw image to a second BFS partition with Installer.

[diver]

Replying to diver:

It doesn't seem to crash but mounting another bfs image in already mounted one creates all sorts of issues.

Yep, the crash is still here in hrev53496.

[pulkomandy]

Had this happen yesterday as well (hrev53632). After it happens the first time, the panic occurs again everytime you unmount a device.

[waddlesplash]

Ticket retargeted after milestone closed

[X512]

I get this after confirming force unmount dialog. hrev54942 x86_64.

[X512]

Script to reproduce:

mkdir /HaikuRiscV
mount haiku-minimum.image /HaikuRiscV

(cd /HaikuRiscV/system ; package extract /boot/data/packages/haiku/generated.riscv64/objects/haiku/riscv64/packaging/packages/haiku.hpkg)

unmount /HaikuRiscV
rmdir /HaikuRiscV

Peplace paths if needed.

[pulkomandy]

Move unsolved issues to beta 4 since there is no chance of fixing them now.

[X512]

Can't reproduce bug with comment:25. Maybe fixed in hrev55862.

[waddlesplash]

Well, if it consistently reproduced before and doesn't now, let's presume so!

[cocobean]

Unmounting packageFS crashes on hrev55862 -> hrev55865 x64 for full haikuporter package builds/packaging. Not consistent if you conduct haikuporter non-builds (patch only).

KDL Message: 'Deleted referenceable object that's not on the stack...'

Steps to reproduce:

1. haikuporter <package>

Expected Results: 'waiting for build package <package> to be deactivated' should complete all build deactivations and unmount successfully.

[X512]

This is probably packagefs, not BFS. Can you get full stack trace from KDL?

[cocobean]

KDL when unmounting packageFS within haikuporter build - Haiku hrev55865 x64

[waddlesplash]

That is indeed a totally unrelated KDL to this ticket.