FreeBSD-provided disk images: problems with UFS, fsck_ufs (fsck_ffs(8)); partition sizes …

[Cath O'Deray]

Why not ZFS by default?

Images are compressed before distribution. I assume that compression is very effective for:

• non-used space (free, never used) in file systems
• non-used swap space.

Why is there so little free space in the file system for the base OS?

Why is so little of the disk given to the swap partition? 1 G is, I believe, false economy.

Below, with UFS (9.6 G used) and so little swap:

• 2,048 MB memory was insufficient to start the system
• a drop into single user mode
• unable to execute sh

Prior to that, nothing exotic. Essentially, I:

1. downloaded the 2021-05-27 (8d5c7813061) FreeBSD-provided image for 14.0-CURRENT on AMD64
2. temporarily gave more memory to the system
3. grew the disk to 128 GB
4. booted in single user mode
5. gpart recover ada0
6. service growfs start
7. exit
8. pkg install poudriere-devel
9. used poudriere to test packaging of a new port (<https://reviews.freebsd.org/D30534>)
10. installed the package
11. pkg install xorg
12. startx
13. ran the new application, quit
14. exit
15. shutdown -p now
16. reduced the memory – assuming that 2,048 MB would be enough to start FreeBSD.

 

[jmos]

• 2,048 MB memory was insufficient to start the system

Done a small test:
~> dmesg | grep memory
real memory = 134217728 (128 MB)
avail memory = 90320896 (86 MB)
There's no problem on boot, login, run programs like Midnight Commander or a webserver, use a different shell etc. - tested all.

 

[Cath O'Deray]

Thanks,

… tested all.

– with swap enabled and limited to a 1 G partition? Output from gpart show, df -h and freebsd-version will help.

I'm accustomed to testing desktop environments with very little memory ▶ <https://old.reddit.com/r/freebsd/comments/nlb7tq/-/gzmib2j/?context=2>, for example.

The problem involving UFS seems to be quite specific.

 

[jmos]

– with swap enabled and limited to a 1 G partition? Output from gpart show, df -h and freebsd-version will help.

Note that gpart show only says that the swap partition exists, but: I've deactivated it. More specific:
root@vacallinehae ~> freebsd-version
13.0-RELEASE
root@vacallinehae ~> gpart show
=> 63 100663233 vtbd0 MBR (48G)
63 1 - free - (512B)
64 100663232 1 freebsd [active] (48G)

=> 0 100663232 vtbd0s1 BSD (48G)
0 96468992 1 freebsd-ufs (46G)
96468992 4194240 2 freebsd-swap (2.0G)

root@vacallinehae ~> df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/vtbd0s1a 45G 24G 17G 59% /
devfs 1.0K 1.0K 0B 100% /dev
root@vacallinehae ~> dmesg | grep memory
real memory = 134217728 (128 MB)
avail memory = 90714112 (86 MB)
root@vacallinehae ~> swapinfo
Device 1K-blocks Used Avail Capacity
root@vacallinehae ~> cat /etc/fstab
# Device Mountpoint FStype Options Dump Pass#
/dev/vtbd0s1a / ufs rw 1 1
# /dev/vtbd0s1b none swap sw 0 0

So you see: Even without swap (otherwise the output of swapinfo differs, also the "#" in my fstab) & 128 MB memory. Another test with 64 MB failed.

 

[Cath O'Deray]

Oh, is that not a FreeBSD-provided disk image?

Here's the partition layout after expanding partition 4 of FreeBSD-13.0-RELEASE-amd64.vhd (from FreeBSD-13.0-RELEASE-amd64.vhd.xz):

 

[jmos]

Oh, is that not a FreeBSD-provided disk image?

OK, a third one. Few minutes ago downloaded VM-IMAGE. Didn't grew its size, but anyway: Works. 128 MB, without swap.
root@freebsd:~ # freebsd-version
13.0-RELEASE
root@freebsd:~ # gpart show
=> 3 10552471 vtbd0 GPT (5.0G)
3 127 1 freebsd-boot (64K)
130 66584 2 efi (33M)
66714 2097152 3 freebsd-swap (1.0G)
2163866 8388608 4 freebsd-ufs (4.0G)

root@freebsd:~ # df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/gpt/rootfs 3.9G 3.6G -48M 101% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/gpt/efiesp 32M 878K 31M 3% /boot/efi
root@freebsd:~ # dmesg | grep memory
real memory = 134217728 (128 MB)
avail memory = 90714112 (86 MB)
real memory = 134217728 (128 MB)
avail memory = 90714112 (86 MB)
root@freebsd:~ # swapinfo
Device 1K-blocks Used Avail Capacity
root@freebsd:~ # cat /etc/fstab
# Custom /etc/fstab for FreeBSD VM images
/dev/gpt/rootfs / ufs rw 1 1
# /dev/gpt/swapfs none swap sw 0 0
/dev/gpt/efiesp /boot/efi msdosfs rw 2 2
root@freebsd:~ #
Used the *.raw.xz image with bhyve:
sh /usr/share/examples/bhyve/vmrun.sh -c 1 -m 128 -t tap0 -d FreeBSD-13.0-RELEASE-amd64.raw Test

 

[Cath O'Deray]

Ignoring (for a moment) the more general questions in the opening post …

---

… maybe I exposed a bug in fsck_ffs(8).

Via fsck_ufs out of swapspace (2011-12-17) and a response:

• FreeBSD bug 163460 – fsck(8): SU+J fsck uses bogus sector size on sparc64 (Closed FIXED)

When recovering after a crash, fsck, when asked to use the journal, either consumes all memory, or crashes otherwise. …

In my case, I wasn't aware of any crash.

I'll try to reproduce the issue with FreeBSD-12.2-RELEASE-amd64.vhd updated to 12.2-RELEASE-p7 …

 

[Cath O'Deray]

Please:

• can anyone name an existing port with a Makefile that's comparable to <https://reviews.freebsd.org/D30534#change-azVMIyBl3Qpj>?

Relevant lines:

BUILD_DEPENDS=    ${PYTHON_PKGNAMEPREFIX}python-distutils-extra>0:devel/py-python-distutils-extra@${PY_FLAVOR}
RUN_DEPENDS=    ${PYTHON_PKGNAMEPREFIX}dateutil>0:devel/py-dateutil@${PY_FLAVOR} \
        ${PYTHON_PKGNAMEPREFIX}pikepdf>0:textproc/py-pikepdf@${PY_FLAVOR} \
        ${PYTHON_PKGNAMEPREFIX}gobject3>0:devel/py-gobject3@${PY_FLAVOR} \
        poppler-glib>0:graphics/poppler-glib

USES=        python gnome gettext
USE_PYTHON=    distutils
USE_GNOME=    intltool:build gtk30

Postscript

I no longer need an answer here. The file is in the FreeBSD ports collection.

 

[Cath O'Deray]

I'll try to reproduce the issue with FreeBSD-12.2-RELEASE-amd64.vhd updated to 12.2-RELEASE-p7 …

Compared to 14.0-CURRENT, this release seems to be crashtastic.

After reducing the base memory from 16,384 to 2,048 MB, a succession of three kernel panics. A four-minute screen recording:

<https://photos.app.goo.gl/ZBjyCqsVdrkHSRW56>

Postscripts

I should attribute these crashes to emulators/virtualbox-ose-additions <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254412>

… not a duplicate of emulators/virtualbox-ose bug 236917

 

[Cath O'Deray]

Back to my greatest dislike of the disk images:

Why not ZFS by default?

Today:

• I edited /etc/rc.conf to enable crash dumps but then dumps did not occur because my edition was lost (this, presumably, would not happen with ZFS) …

 

[Cath O'Deray]

More apparent ugliness with UFS, broken installations of software: <https://forums.FreeBSD.org/threads/80695/post-515064>

 

[Cath O'Deray]

More ugliness with UFS. In addition to the broken installations of software, I found myself unable to use sudo.

/usr/local/etc/sudoers was empty, which surprised me. The prior edition with visudo(8) was very memorable.

I'm troubled by the amounts of data that seem to be lost, with UFS, when the kernel panics.

Why do FreeBSD-provided disk images not use ZFS?

 

[zirias@]

IMHO, your crusade against UFS is ill-advised. UFS is a solid, old, well-proven and simple filesystem. In a typical VM scenario where the host (or whatever provides the storage) already has elaborate stuff in place – this could be for example a host using ZFS, with zvols backing the virtual disks – ZFS inside the VM could often be just a waste of resources.

If you experience specific bugs with UFS, better hunt them down and report them. Nowadays, from all I know and experience, UFS with SU+J is extremely robust.

 

[Cath O'Deray]

… I dont trust UFS … incredibly fragile on unsafe shutdown…

More ugliness with the FreeBSD-provided disk image that uses UFS.

An endless stream of failures affecting VirtualBox:

 

[Cath O'Deray]

hunt them down

It's unnecessarily difficult to hunt file system-related bugs when the file system loses data that may be relevant to the bugs.

Why do FreeBSD-provided disk images not use ZFS?

 

[zirias@]

I guess I explained that. Whatever is wrong with your VMs, you'd have to prove that's related to UFS.

 

[Cath O'Deray]

Essentially:

• UFS is a file system
• I'm losing files, or editions to file content, repeatedly, and frankly I'd prefer to not spend time debugging file systems, I'm not a developer.

In my years of using Z-410 then Zevo then ZFS then OpenZFS, I never encountered anything like these losses.

Why do FreeBSD-provided disk images not use ZFS?

 

[zirias@]

So, just babbling, right?

I guess repeating the question all over again means you need a repetition of the answer:

Because ZFS inside a VM rarely makes any sense.

 

[Cath O'Deray]

So, just babbling, right?

You've probably heard this before: Zirias, don't be so damned rude. It deserves ignorance. Kindly step away now.

Positive contributions from other readers will be welcome.

 

[zirias@]

So, what exactly did you not get?

 

[_martin]

It seems your crashes are coming from VirtualBox video drivers being loaded. At least from the short glance of video I had that you've posted.
I'd suggest to try it without them (either by disabling them, disabling display manager, service that does load them as dependency..)

I've downloaded the 14.0 vmdk and placed it into my 512MB VM. Note 14 is a current snapshot, do expect problems. I too ran out of memory. It seems fsck_ufs process runs out of memory (you can disable this actualy in rc.conf).
In a single mode I did a quick strace check and found out last mmap it tries to do is of size 0xE0000000, i.e. 3G. Not sure why, but again, it's 14.0. That's why it rans out of memory.

 

[Cath O'Deray]

Thank you,

It seems your crashes are coming from VirtualBox video drivers being loaded. …

FreeBSD bug 254412 – emulators/virtualbox-ose-additions - Boot time crash - Sleeping thread owns a non-sleepable lock

• comment 5 – FreeBSD 13.0-RELEASE-p1, UFS (FreeBSD-provided disk image) – observing panics but failing to get crash dumps (broken /etc/rc.conf – recent edition lost/missing) then getting dumps that were useless (unusable devel/gdb and textproc/source-highlight – recently installed files missing)
• comment 6 – FreeBSD 13.0-RELEASE-p1, UFS – eventually I got a usable dump, backtrace at lines 155–172 (consistent, at a glance, with the backtrace in comment 0)
• comment 7 – FreeBSD 13.0-RELEASE-p1, ZFS, ample swap space –reproducibility of panics, and a workaround
• comment 8 identifies 254412 as a probable duplicate of 236917 – sorry, I was horribly wrong, not a duplicate.

 

[Cath O'Deray]

…

• 2,048 MB memory was insufficient to start the system
• a drop into single user mode
• unable to execute sh

…

… It seems fsck_ufs process runs out of memory …
In a single mode I did a quick strace check and found out last mmap it tries to do is of size 0xE0000000, i.e. 3G. …

Many thanks. Would you agree that a bug report is appropriate?

(When I searched Bugzilla, at the weekend, I found nothing relevant.)

… (you can disable this actually in rc.conf). …

Please, how so?

Would this suppress all automated runs of fsck_ffs(8) – even where there's a dirty flag for UFS – and in the absence of an automated check, would the system automatically come up multiuser?

 

[Aeterna]

I would suggest to install FreeBSD from iso in VM. It is difficult to say if the problems that you encounter are really related to FreeBSD or maybe botched VM Client image.
Also please read this report:
https://forums.virtualbox.org/viewtopic.php?f=6&t=101544
it looks like similar issues are related to VM host, not VM client

I am now unable to get any VMs to boot (freezes shortly after start), they all freeze about when I think the file system is mounting

So the issue may not be related to VM client at all.

 

[richardtoohey2]

You've probably heard this before: Zirias, don't be so damned rude. It deserves ignorance. Kindly step away now.

I think you are being rude, too.