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.
Building an ARM64 home server the hard way
111–119 of 119 posts
Re: Building an ARM64 home server the hard way
#112Earlier 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.
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
#113Earlier 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.
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
#114Re: Building an ARM64 home server the hard way
#115Do 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/
Re: Building an ARM64 home server the hard way
#116Earlier 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…
Re: Building an ARM64 home server the hard way
#117Earlier 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.
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
#118Earlier 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!
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> 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.
My laptop is also a single board computer, technically, so what?