Compiling bfs for fuse

Development
1

It just happens that I found this article https://www.haiku-os.org/guides/daily-tasks/access_bfs_with_fuse/. I tried that on my FreeBSD system (my old sturdy Thinkpad x220) so that I can access the freshly installed beta2 installation.
The build chain for cross compiling Haiku on FreeBSD works, but regardless what I try the bfs_fuse target is always unknown and fails.
Any tip on that?

2

I did this relatively recently on Linux because I needed write support, and it worked well. I don’t remember any particular problems but if no one else has any ideas I will take a look at what I did.

Edit: I wrote it up here, maybe that will help? Problems booting on a Sony Vaio P

3

Thanks for the link, I found my error now.
I need to issue jam '<build>bfs_fuse' and not jam 'bfs_fuse'.
This happens when you don’t know jam :-). But my BFS partition does not mount, some partition size vs. file system size issue. Strange, as Haiku itself boots without problems.

4

Please report this on Trac.

5

I get this error here when trying to mount my bfs partition with fuse:

bfs_fuse /dev/ada0p8 ~/haiku
bfs: Disk size (138976911360 bytes) < file system size (138977214464 bytes)!
bfs: Mount:207: Invalid argument
bfs: bfs_mount:184: Invalid argument
Error: Mounting FS failed: Invalid argument

But my partition seems to look good (output of gpart list):

  1. Name: ada0p8
    Mediasize: 138977214464 (129G)
    Sectorsize: 512
    Stripesize: 4096
    Stripeoffset: 0
    Mode: r0w0e0
    efimedia: HD(8,GPT,345c2ac9-ac6e-a24d-ae52-7f53eb4aab7b,0x27b65800,0x102dd800)
    rawuuid: 345c2ac9-ac6e-a24d-ae52-7f53eb4aab7b
    rawtype: 42465331-3ba3-10f1-802a-4861696b7521
    label: Haiku
    length: 138977214464
    offset: 341125890048
    type: !42465331-3ba3-10f1-802a-4861696b7521
    index: 8
    end: 937701375
    start: 666261504

So where is the difference of 592 blocks/303104 bytes coming from?

6

Oh, sorry, I just saw that you did that already.
I will report the partition size issue, too.

7

gpart does not check the filesystem length, so it wouldn’t see this problem.

This looks a bit dangerous, it means the bfs filesystem is allows to use disk space that’s not actually inside the partition and may be used by something else. You should probably fix the partition layout before anything bad happens :confused:

8

No, I think the layout is perfectly fine, the FreeBSD relevant partitions were created using gpart, the bfs partition was created by Drive Setup during a fresh beta2 Haiku install. So I assume a bug in the fuse relevant parts or a one in the FreeBSD fuse implementation.

9

So, it took awhile (related source is scattered over the complete source tree) but I finally found the issue, but I am unsure about a possible fix. With FreeBSD the following lines in haiku/src/tools/fs_shell/unistd.cpp (line 228…) are relevant:

// Ignore errors, this way we can use memory devices (md%d)
ioctl(fd, DIOCGSECTORSIZE, &disklabel.d_secsize);
ioctl(fd, DIOCGFWSECTORS, &disklabel.d_nsectors);
ioctl(fd, DIOCGFWHEADS, &disklabel.d_ntracks);
ioctl(fd, DIOCGMEDIASIZE, &mediaSize);

if (disklabel.d_nsectors == 0) {
	// Seems to be a md device, then ioctls returns lots of
	// zeroes and hardcode some defaults
	disklabel.d_nsectors = 64;
	disklabel.d_ntracks = 16;
}

disklabel.d_secperunit = mediaSize / disklabel.d_secsize;
disklabel.d_ncylinders = mediaSize / disklabel.d_secsize
	/ disklabel.d_nsectors / disklabel.d_ntracks;

As you can see, there is a chained division of integers in the last line to calculate the cylinders.

Later on the media size is recalculated in haiku/src/add-ons/kernel/file_systems/shared/DeviceOpener.cpp, line 128:

if (_size) {
	*_size = 1ULL * geometry.head_count * geometry.cylinder_count
		* geometry.sectors_per_track * geometry.bytes_per_sector;

In my case, FreeBSD reports the correct media size with the ioctl, but 63 sectors which of course introduces a rounding error (138977214464 / 63 …).

So why not report the correct media size in the first place? Why is this old stupid C/H/S conversion used?

10

Is it possible (license?) that I upload all files necessary for bfs_fuse to GitHub with a simple Makefile? This would make integration into a ports or package system much easier, since you do not need to download the complete source tree and buildtools.

11

So how did you fix it in the end?

12

I use a fixed geometry like the Linux implementation does. But I was so far too lazy to prepare a patch.