Raspberry Pi 4 announced

msplsh said:
.............
AArch64 is destined for Tier 1 support, so this and the B+ have a lot to look forward to.
Click to expand...

My tests with all three major BSDs on several SBCs in the last few days, however, speak a completely different language:
Tier1 is light-years away, both in terms of hardware and software.

e.g. Hardware: Look at the headline: The Power to Serve
How could FreeBSD serve ZFS on a hardware platform, which
has only 1 cheaper SBC on the market with ECC-RAM?
Especially, considering that the board is of course sold out ...

e.g. Software: I have never seen FreeBSD crashing like this (down to total data loss),
like on these SD-cards & USB-sticks on the RPI3. for me this happened 4 times in a few days!
regardless of whether it was due to the hardware or software:
This is never Tier 1-destined

As a developer you ask yourself whether you want to invest all those unpaid working hours
in a platform which is , as of now, simply incompatible with the key-features of FreeBSD
( Data-integrity, Stability, speed... and so on) .
I would say: why not (for fun) , to save electricity and maybe only because of the hope that time will change the current massive limits of this platform -
support for aarch64- why not ..but unfortunately currently more Tier8 or Tier9 than Tier1 ?

Perhaps good for Raspbian to add 2 HDMI-ports , for FreeBSD useless.

For the low price of the RPI4 we will get the fun we paid for but we will never get a Tier 1 production - ready FreeBSD because these SBCs are not built for The Power to Serve.
 
I think it is obvious that FreeBSD will use UFS on RPi. ZFS on 1-2GB RAM and SD card sounds like bad idea. The price for 4GB version goes too far from the initial idea for cheap SBC. I will prefer NUC or second hand Lenovo Tiny.
 
I was thinking for things like ZFS replication to a USB3 HDD at home, nothing particularly performance intensive. Even 1GB RAM is fine at a push for something like that (a friend currently does this with an RPi3, albeit with hampered Ethenet performance and over USB2).
 
I'm not talking AArch64 Tier 1 support as a theoretical wish, it's a funded project of the FreeBSD Foundation

FreeBSD ARMv8 64-bit ARM port | FreeBSD Foundation

Developers: Andrew Turner and Semihalf sp.j. Officially known as AArch64, the 64-bit ARM architecture is also known as ARMv8 and arm64. The 64-bit ARM architecture is expected to find use in traditional server markets, in contrast to the embedded and mobile markets where 32-bit ARM is widely...
www.freebsdfoundation.org www.freebsdfoundation.org
 
forquare said:
Reminder that ZFS on non-ECC RAM still has better data integrity than most other file systems on the same hardware.
Click to expand...
perhaps true for x86 with a little luck....
I give you a hint :
e.g. U-Boot for aarch64 is currently not under BSD- "control" .
forquare said:
... USB3 HDD at home ....
Click to expand...
at home we can do all unsupported things we want ... at home I plugged in an USB- HDD (via power passive Dongle) and it crashed the dongle to electrical death .
long story pros and cons aarch64 consumer- hardware...
but for FreeBSD i would say:
arm64 is currently a load of crap ... has to got to Tier 3 ...
or the Foundation and Core Team would say:
O.K., we have the manpower to support it so let's go
 
6502 said:
I think it is obvious that FreeBSD will use UFS on RPi. ZFS on 1-2GB RAM and SD card sounds like bad idea. The price for 4GB version goes too far from the initial idea for cheap SBC. I will prefer NUC or second hand Lenovo Tiny.
Click to expand...
Let's say simply
ZFS is slow ... but fine.
UFS is fast for RPI.
 
6502 said:
RPi is ideal for Media Player. BTW, it is time to add SATA port.
Click to expand...

I've read RPi4 has some heating issues as a media box, even after adding a heatsink. I use an AMLogic platform for that. My media box runs a version of Linux (CoreELEC), but at some point I'd like to try building a media box with FreeBSD on an AMD APU, would be an interesting albeit a challenging project. Never really considered FreeBSD on ARM, might be a stretch.
 
Hi,

What about mini HDMI?

I find that this mini HDMI is a big drawback

Kind regards
6651

https://miro.medium.com/max/2400/1*gH0mrG3eebvHt4KTj9oOig.png
 
ekingston said:
What is the issue with mini HDMI? Other than needing an adapter (or cable with mini-hdmi on one end)?
Click to expand...

the adapter is rather the problem. I go to meeting rooms with the pi, without thinking about forgetting the adapter. Just the pi. ...

my monitor is happy with large hdmi, it is standard today and it is big enough not to break easily.
 
It is a pity the initial spec were an Apri Fool ... I belived it, as Fox Mulder would ;)

In this case I see no reason at all to leave the BeagleBone. This device has no PWM and no ADC. For electronics projects is not much interesting.
 
Spartrekus said:
Hi Nico,
what would be the best alternative to RPI 3 or 4 ?
Click to expand...

Hi Spartrekus !

The only two boards similar to RPI i tried are the RPI (2|3) [not sure of the number right now, I am at airport] and the BeagleBone Black/Green.

I saw many reviews of other machines online and, in my opinion, they are more similar to the RPI than to the BBB. If you want to play with electronics, the is BBB is superior to the RPI from all points of view. It is true, it costs a bit more.

What I particularly love in the BBB is that it has these features other SOC usually do not have:
-] PWM: this is very useful for motors. Bitbanging a GPIO is not a serious option.
-] ADC: this is useful if you want to read an analog signal, e.g. how much light there is in your room.
-] PRUSS: these are 2 little processors separate from the main CPU that you can use for real time stuff.
-] eMMC + SSD: that is on BBB you have about 4G on boad storage memory, i usually install FreeBSD there. I use the SSD only for install or experiments.
-] software controllable pull(Up|Down) on GPIO

The RPI is superior to BBB for one thing AFAIK, video streaming, because it has a specific on board chip for that.

Most of what I know on this stuff I learnt on Derek Molloy book "Exploring BeagleBone". It is a very good book.

bye
 
ucomp said:
... serve ZFS on a hardware platform, which has only 1 cheaper SBC on the market with ECC-RAM?
Click to expand...
As forquare already said: ECC is not a prerequisite for ZFS. On the contrary, ZFS without ECC is still better (in terms of data durability) than other file systems without ECC. What is however true: since ZFS solves quite a few other data corruption issues (using checksums and scrubbing), the next big gain to be made once one has ZFS running is to use ECC. So ECC helps relatively more on ZFS than on other file systems.

I have never seen FreeBSD crashing like this (down to total data loss),
like on these SD-cards & USB-sticks on the RPI3. for me this happened 4 times in a few days!
Click to expand...
I ran FreeBSD on a RPi3B for a few months, including a few days of intense prototyping on the lab bench. I don't remember it ever crashing. Nor did I have any data loss episode.

6502 said:
I think it is obvious that FreeBSD will use UFS on RPi. ZFS on 1-2GB RAM and SD card sounds like bad idea.
Click to expand...
Why is ZFS worse than UFS on SD cards? Rather on the contrary, if you think through how ZFS lays out data (log-based), it probably benefits from a FTL (flash translation layer) and large blocks more than other file systems. And we know that for small file systems, you can very successfully run ZFS without terribly much memory. I have about a handful of TB of ZFS disk space in production on a 3GB 32-bit machine, which has been stable for several years.

The price for 4GB version goes too far from the initial idea for cheap SBC.
Click to expand...
How does the price for the 4GB version compare to competitive systems? It seems to me that being under $100 it is still very cheap.

Spartrekus said:
Let's say simply
ZFS is slow ... but fine.
UFS is fast for RPI.
Click to expand...
Do you have any evidence for ZFS being particularly slow on RPi? Show me the data.
 
ralphbsz said:
As forquare already said: ECC is not a prerequisite for ZFS. On the contrary, ZFS without ECC is still better (in terms of data durability) than other file systems without ECC. What is however true: since ZFS solves quite a few other data corruption issues (using checksums and scrubbing), the next big gain to be made once one has ZFS running is to use ECC. So ECC helps relatively more on ZFS than on other file systems.


I ran FreeBSD on a RPi3B for a few months, including a few days of intense prototyping on the lab bench. I don't remember it ever crashing. Nor did I have any data loss episode.


Why is ZFS worse than UFS on SD cards? Rather on the contrary, if you think through how ZFS lays out data (log-based), it probably benefits from a FTL (flash translation layer) and large blocks more than other file systems. And we know that for small file systems, you can very successfully run ZFS without terribly much memory. I have about a handful of TB of ZFS disk space in production on a 3GB 32-bit machine, which has been stable for several years.


How does the price for the 4GB version compare to competitive systems? It seems to me that being under $100 it is still very cheap.


Do you have any evidence for ZFS being particularly slow on RPi? Show me the data.
Click to expand...
what about if the FreeBSD RPI3b servers a sshfs server with sshfs fuse for several machines, with two 6TB disks usb ?
The 2 x 6tb harddisks are powered by hub 3.0 high power on rpi3b.
Then, ZFS or UFS?
 
I have no idea about running sshfs. I've seen it go very wrong when administered badly.

But in general, if you have two disks, I would always run ZFS and use RAID (in this case mirroring). Unless you really don't care about your data, in which case you don't need any file system.
 
Spartrekus said:
what about if the FreeBSD RPI3b servers a sshfs server with sshfs fuse for several
Click to expand...

Remember sshfs is very inefficient; it can only really do what SSH can do, so appending files generally involves a complete replace. A proper network filesystem like NFS or Samba is generally better. And to be honest, for batches (which sshfs is generally mentioned for), then rsync is still better.
 
ralphbsz said:
I have no idea about running sshfs. I've seen it go very wrong when administered badly.

But in general, if you have two disks, I would always run ZFS and use RAID (in this case mirroring). Unless you really don't care about your data, in which case you don't need any file system.
Click to expand...

for the fuse sshfs, I use the easy way if I have a distant machine.
sshfs is cool with a tunnel, so that you can use your data anywhere anytime anymachine.

ntpd_enable="YES"
ntpd_sync_on_start="YES"
sshd_enable="YES"
fusefs_enable="YES"
allscreens_flags="-f terminus-b32"
#apache24_enable="YES"


nsystem( " kldload fuse ; chmod 777 /dev/fuse " );
nsystem(" sysctl vfs.usermount " );
nsystem(" sysctl vfs.usermount=1 " );
nsystem(" sysctl vfs.usermount " );
 
ralphbsz said:
....
Click to expand...
well, Ralph, thanks for sharing your feedback / experiences with the arm-platform .
you seem to consider it as "Tier1/SD-card-ZFS-production-ready" and I considered it as "Tier3- crap" (at the moment) ....
should be something something like Tier 2 ( what it really is ) . :)
--
I wanted to work on a slightly more complex port for arm64, where all 3 major BSDs are to be taken into account. As long as there are enough happy arm users like you, I think again about whether I should fish my SBC cluster out of the recycle bin ;-) So actually fun



--- edit:--
ralphbsz said:
...
in production on a 3GB 32-bit machine...
Click to expand...
by the way ...
i386 != arm;
 
ucomp said:
you seem to consider it as "Tier1/SD-card-ZFS-production-ready" and I considered it as "Tier3- crap" (at the moment) ....
Click to expand...
I did not say that ARM is Tier 1. Matter-of-fact, I didn't say that anything about Tiers. What I did say is that when I ran it, I did not experience the frequent crashes that you seem to have experienced: I had no crashes.

i386 != arm;
Click to expand...
I am very aware of that. My point was that it is perfectly possible to serve ZFS on a 32-bit machine with a small number of GB of RAM. From an architectural point of view (CPU, memory, interfaces), an RPi4 with 4GB should do at least as well as my home server, which handles the workload just fine.
 
You must log in or register to reply here.
Back
Top