Help! Consistent failure with a huge (4.4GB) disk image I'd like to mount or restore!

About two years ago I sold off all my BeOS hardware.

Before I got rid of everything though, I made a 4.4GB image of the disk that had all my development work / important files on it. I scp-ed the file to my iMac, and burnt the image file (as a file) on a DVD.

The idea, was that when Haiku got mature enough, and when I had a working x86 box that would be able to boot it natively, I’d mount the image on the DVD, and recover all my old stuff.

Fastforward two years – I’ve now got a laptop that will boot Haiku (beautifully!) on the raw hardware, as well as in VirtualBox. Even the wireless is working!

I pulled out that DVD today, and I’ve spent quite some time trying multiple methods of getting the data off it.

Each time, I run into what appears to be a bug with Haiku.

If I try to mount the image file with tracker, it immediate looks like a race condition, and Tracker hangs – never to be killed. Rebooting is the only way to get things back to normal.

If I try to copy the image file with tracker, it looks a lot like the linked screen shot above. Once the memory cache gets pretty full, both processors seem to get into contention (race condition in memory management?) and everything stalls.

If I try to use DD to write the image to a partition, the same thing eventually happens (although much faster).

If I use the BFSTools recover program, same thing. The cache continues to grow, then all of a sudden (after about 1024MB of data read from device) things just… stop.

This is happening on a Dell Latitude D620, 4GB of physical RAM.

Is this a bug? Does anyone have suggestions?


Use Linux. :slight_smile:

You should be able to mount the image read-only in Linux. If bfs filesystem then use mount -t befs “image-name” “mount-point”.

Looks like Haiku is trying to read the whole image into cache memory first. Just my guess. You should report this bug.

General Mailing List is better for this question to get response from Ingo or Axel or other developer which are more involved with the kernel code.

EDIT: can you also try mounting in haiku from terminal (using mount command) and see what that does?

since it is an image I think you have to mount it on a loop for instance

mount -t bfs -o loop image.img mountpoint

Yeah, I’ve tried the mount on the command line a few times as well. Same issue there. You can watch the page catch go up and up and up, and then… stall

I’ve had someone recommend using the FUSE version of bfs – that would be -perfect-. So I’ll try that next.

Linux has an old, read-only implementation of bfs, called ‘befs’. No need to work with fuse, etc, on my fedora it’s just there, and it has worked fine.

What he said:

[quote=tonestone57]Use Linux. :slight_smile:
You should be able to mount the image read-only in Linux. If bfs filesystem then use mount -t befs “image-name” “mount-point”.

I kept pretty much all my BeOS-era stuff on a IDE hard disk after moving to a new computer unsupported by BeOS. Unfortunatly, I didn’t have anymore an IDE controler to connect to when recently I plan to access its content again, except for an IDE-USB adapter which is not supported by our USB mass storage driver.

Instead, I booted under Linux, plugged the disk on and dd’ed it to a free partition on a SATA disk: (raw mode, dd if=/dev/sd of=/dev/sd)
One reboot later, the volume was mounting fine under Haiku.

Give it a try, except if you can’t find ~5Gb free space on disk. You may even find easier to just write the image on these cheap 8Gb usb keys we found now…

And anyway, it’s obviously a bug, as copying a big file should not hang the system.
Search for existing bug ticket to reopen, or create new one.

And it’s nice to see you back :wink:

More details on this one.

I’m only able to duplicate the issue when copying from my DVD-ROM.

I’ve tried huge files from disk to disk, and it works fine. But for some reason from DVD-ROM to disk, it fails. Even mounting the image directly from the DVD-ROM as a read-only filesystem fails.

I was able to work around the issue using VirtualBox on my linux partition.

VBoxManage convertfromraw Backup.img Backup.vdi --variant Fixed

Then added the disc to the Haiku VM and booted. Once in Haiku, I mounted the drive, copied the data I wanted, and was very happy to see my old source code once again. :slight_smile:

Thanks for the ideas, guys. I’m opening a trac issue for this one.

I didn’t expect an IDE drive to survive a 3 or 4 year hiatus. I expected optical media to still be common though.

Looks like it was a good call in hindsight.

I could have dd’ed it to the drive, but the partition I wanted to target the contents to was the only free partition on the drive, and I didn’t want to shrink the size of that partition. Catch 22 on that.

VirtualBox to the rescue!