Live data from Hacker News

Building an ARM64 home server the hard way

jforberg.se

111–119 of 119 posts

Re: Building an ARM64 home server the hard way

#111
post #110
post #106

Earlier quoted context omitted.

BTRFS is buggy?

Yes, especially for external drives. See: https://lore.kernel.org/all/20200326013007.GS15123@merlins.o... ... and many other problems.

I was literally recommended to use BTRFS because it has been battle tested and proven. I should probably have done more research but given its maturity (we're in 2023 after all), I feel a bit let down.

Re: Building an ARM64 home server the hard way

#112
post #111
post #110

Earlier quoted context omitted.

Yes, especially for external drives. See: https://lore.kernel.org/all/20200326013007.GS15123@merlins.o... ... and many other problems.

I was literally recommended to use BTRFS because it has been battle tested and proven. I should probably have done more research but given its maturity (we're in 2023 after all), I feel a bit let down.

BTRFS is far better designed than other recent linux filesystems. It's just that linux always was and always will be very very buggy. If you want less bugs, use the oldest possible FS that is still usable. That's probably ext2.

Most problems with btrfs is that it fails to mount in many situations and there's no automated fsck to fix it, requiring manual intervention; in fact running fsck on btrfs is considered a very bad thing. This makes it OK for desktop, but not at all suitable for headless servers and other unsupervised machines.

Speaking of bad design, F2FS for example, a filesystem designed for flash drives, keeps both primary and backup superblocks in the same flash erase block. If that block gets corrupted the entire fs is lost.

Re: Building an ARM64 home server the hard way

#113
post #30

Earlier quoted context omitted.

I understand that part. What I'm talking about specifically is part of a bootloader, see for example this page in the documentation of SWUpdate: https://sbabic.github.io/swupdate/bootloader_interface.html By adding communication between the OS and the bootloader it's possible to implement redundant updates for whole partitions (specifically A/B-updates with a boot counter). U-Boot supports this (depending on the stat…

The tow-boot software devs goes out of the way to say they are offering a boring PC boot loader experience so I wouldn’t expect any advanced features other than booting from devices.

PC boot loaders have been able to fall back to previous configurations on boot failure ("automatic redundant OS upgrades") for a long time[1], so that's not a valid excuse.

https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/

https://www.gnu.org/software/grub/manual/grub/html_node/fall...

https://www.gnu.org/software/grub/manual/legacy/Booting-fall...

[1]: Minimum about 23 years, from personal use in creating a product with A/B-root partitions.

Re: Building an ARM64 home server the hard way

#115

Do it the easy way with Oracle cloud’s free tier and get Arm Ampere A1 CPUs, 24GB RAM, and 10TB egress with the hard part being creating an account which requires a credit card. https://www.oracle.com/cloud/free/

This sounds awesome but the idea of giving Oracle my credit card is terrifying.

Re: Building an ARM64 home server the hard way

#116
post #112
post #111

Earlier quoted context omitted.

I was literally recommended to use BTRFS because it has been battle tested and proven. I should probably have done more research but given its maturity (we're in 2023 after all), I feel a bit let down.

BTRFS is far better designed than other recent linux filesystems. It's just that linux always was and always will be very very buggy. If you want less bugs, use the oldest possible FS that is still usable. That's probably ext2. Most problems with btrfs is that it fails to mount in many situations and there's no automated fsck to fix it, requiring manual intervention; in fact running fsck on btrfs is considered a very…

That's interesting. I've always thought ext3fs would at least be safer than ext2 seeing that ext2 isn't a journaling filesystem. What happens if you abruptly shut it down e.g. a 1000 times.

Re: Building an ARM64 home server the hard way

#117
post #116
post #112

Earlier quoted context omitted.

BTRFS is far better designed than other recent linux filesystems. It's just that linux always was and always will be very very buggy. If you want less bugs, use the oldest possible FS that is still usable. That's probably ext2. Most problems with btrfs is that it fails to mount in many situations and there's no automated fsck to fix it, requiring manual intervention; in fact running fsck on btrfs is considered a very…

That's interesting. I've always thought ext3fs would at least be safer than ext2 seeing that ext2 isn't a journaling filesystem. What happens if you abruptly shut it down e.g. a 1000 times.

I won't use anything journaled on SSDs.

What happens? I don't know... fsck would run automatically on reboot, fix the errros and recover part of the last file written in /lost+found/

But why would a server abruptly shut down 1000 times?? I already said btrfs is good enough for desktops and other interactive/supervised systems. And data loss on servers is recovered from backups, not journals!

Re: Building an ARM64 home server the hard way

#118
post #117
post #116

Earlier quoted context omitted.

That's interesting. I've always thought ext3fs would at least be safer than ext2 seeing that ext2 isn't a journaling filesystem. What happens if you abruptly shut it down e.g. a 1000 times.

I won't use anything journaled on SSDs. What happens? I don't know... fsck would run automatically on reboot, fix the errros and recover part of the last file written in /lost+found/ But why would a server abruptly shut down 1000 times?? I already said btrfs is good enough for desktops and other interactive/supervised systems. And data loss on servers is recovered from backups, not journals!

Restoring from backups can be tedious and time consuming. For example, if you have a database and PITR system, you may have to replay WALs until you get the point in time where the server failed.

XFS is known to be extremely robust for servers - and it's journaled. Most servers nowadays are SSD.

Re: Building an ARM64 home server the hard way

#119
post #22

> The total cost comes to around €350 A few weeks ago I bought an used intel nuc7 with a 7th gen core i5… for 150€. It came with a 120gb ssd, 4gb ram and a power brick. I still don’t see the value in this SBCs used as home servers.

NUC is a single board computer :) If you think the price is high, I would point out that the SSD I used cost €200 new when I purchased it back in mid 2022. A used 120 GB SSD by contrast can be had for maybe €10 which alone would explain the difference in cost. Now if 120 GB is enough for your application, that's a good value so more power to you.

> NUC is a single board computer :)

My laptop is also a single board computer, technically, so what?

Post reply on HN