Hi all, I have a question on JeOS images being built for ARM boards. I suppose that we agree that most target SBCs use microSD cards to store and run the OS. There are exceptions though. Currently, half of JeOS images are supplied with ext4 and the other half - btrfs. And frankly speaking, I cannot figure out the rule why some specific board receives JeOS with ext4 instead of btrfs or vice-versa. I suppose this was related somehow to btrfs support in u-boot, right? Another consideration. Does anybody know any research on what FS is the most friendly to SD cards? -- With best regards, Matwey V. Kornilov
Hello, On 2021-01-06 T 18:56 +0300 Matwey V. Kornilov wrote:
I have a question on JeOS images being built for ARM boards. I suppose that we agree that most target SBCs use microSD cards to store and run the OS. There are exceptions though.
Currently, half of JeOS images are supplied with ext4 and the other half - btrfs.
I think, this is based on personal choice of the person who creates the images...
And frankly speaking, I cannot figure out the rule why some specific board receives JeOS with ext4 instead of btrfs or vice-versa. I suppose this was related somehow to btrfs support in u-boot, right?
Some historic background on the SUSE Linux Enterprise side (from around 2016): one of the reasons to use btrfs for microSD cards for SLES on RPi3 was that, combined with compression on the filesystem level, the number of IOPS needed is reduced, and booting (and other IO related activities) speeds up, as the cost of (de)compression is lower than the IO latency. So long - MgE
Another consideration. Does anybody know any research on what FS is the most friendly to SD cards?
-- Matthias G. Eckermann, Director Product Management Linux Platforms SUSE Software Solutions Germany GmbH - Maxfeldstr. 5 - 90409 Nürnberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
ср, 6 янв. 2021 г. в 20:04, Matthias G. Eckermann <mge@suse.com>:
Hello,
On 2021-01-06 T 18:56 +0300 Matwey V. Kornilov wrote:
I have a question on JeOS images being built for ARM boards. I suppose that we agree that most target SBCs use microSD cards to store and run the OS. There are exceptions though.
Currently, half of JeOS images are supplied with ext4 and the other half - btrfs.
I think, this is based on personal choice of the person who creates the images...
And frankly speaking, I cannot figure out the rule why some specific board receives JeOS with ext4 instead of btrfs or vice-versa. I suppose this was related somehow to btrfs support in u-boot, right?
Some historic background on the SUSE Linux Enterprise side (from around 2016): one of the reasons to use btrfs for microSD cards for SLES on RPi3 was that, combined with compression on the filesystem level, the number of IOPS needed is reduced, and booting (and other IO related activities) speeds up, as the cost of (de)compression is lower than the IO latency.
As far as I understand, you have to mount btrfs with `compress' option to force the compression by default. From what I see in openSUSE JeOS, there is no `compress' in /etc/fstab by default.
So long - MgE
Another consideration. Does anybody know any research on what FS is the most friendly to SD cards?
-- Matthias G. Eckermann, Director Product Management Linux Platforms SUSE Software Solutions Germany GmbH - Maxfeldstr. 5 - 90409 Nürnberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
-- With best regards, Matwey V. Kornilov
On 2021-01-06 T 20:15 +0300 Matwey V. Kornilov wrote:
On 2021-01-06 T 18:56 +0300 Matwey V. Kornilov wrote:
Some historic background on the SUSE Linux Enterprise side (from around 2016): one of the reasons to use btrfs for microSD cards for SLES on RPi3 was that, combined with compression on the filesystem level, the number of IOPS needed is reduced, and booting (and other IO related activities) speeds up, as the cost of (de)compression is lower than the IO latency.
As far as I understand, you have to mount btrfs with `compress' option to force the compression by default. From what I see in openSUSE JeOS, there is no `compress' in /etc/fstab by default.
Oops, I did not know. The images we are shipping for the Raspberrys for SUSE Linux Enterprise Server 12 and 15 do have this enabled, and it works nicely (and saves some space, ...). So long - MgE -- Matthias G. Eckermann, Director Product Management Linux Platforms SUSE Software Solutions Germany GmbH - Maxfeldstr. 5 - 90409 Nürnberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
ср, 6 янв. 2021 г. в 20:25, Matthias G. Eckermann <mge@suse.com>:
On 2021-01-06 T 20:15 +0300 Matwey V. Kornilov wrote:
On 2021-01-06 T 18:56 +0300 Matwey V. Kornilov wrote:
Some historic background on the SUSE Linux Enterprise side (from around 2016): one of the reasons to use btrfs for microSD cards for SLES on RPi3 was that, combined with compression on the filesystem level, the number of IOPS needed is reduced, and booting (and other IO related activities) speeds up, as the cost of (de)compression is lower than the IO latency.
As far as I understand, you have to mount btrfs with `compress' option to force the compression by default. From what I see in openSUSE JeOS, there is no `compress' in /etc/fstab by default.
Oops, I did not know. The images we are shipping for the Raspberrys for SUSE Linux Enterprise Server 12 and 15 do have this enabled, and it works nicely (and saves some space, ...).
You are right. The compression was enabled one year ago. Probably the system I checked was deployed before that.
So long - MgE
-- Matthias G. Eckermann, Director Product Management Linux Platforms SUSE Software Solutions Germany GmbH - Maxfeldstr. 5 - 90409 Nürnberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
-- With best regards, Matwey V. Kornilov
Matwey V. Kornilov wrote:
Hi all,
I have a question on JeOS images being built for ARM boards. I suppose that we agree that most target SBCs use microSD cards to store and run the OS. There are exceptions though.
Currently, half of JeOS images are supplied with ext4 and the other half - btrfs. And frankly speaking, I cannot figure out the rule why some specific board receives JeOS with ext4 instead of btrfs or vice-versa.
It might be sensible to produce images for both? -- Per Jessen, Zürich (0.2°C)
On 06/01/2021 16:56, Matwey V. Kornilov wrote:
Another consideration. Does anybody know any research on what FS is the most friendly to SD cards?
I believe that would be FAT32 which is what the firmware is optimised for but of course not very useful for a root fs. F2FS is a flash optimised FS. One thing that I found out is that a lot of SD card vendors explicitly have an expected start sector on SD cards. Internally SD card flash is segmented into 4MiB blocks or something like that. Hence most SD cards formatted so that the standard FAT32 partition starts at block 8192. The Official Raspian Images respect this too by placing the boot partition at sector 8192 (you can validate this with `fdisk -l /dev/mmcblk0`). This could make a difference in performance. I tried to test this by building an image locally but failed due to some weird dependency issues. You should be achieve the alignment by changing the <type> tag in the .kiwi like `<type image="oem" disk_start_sector="8192">` I would like to benchmark and compare multiple FS as well as the difference the alignment could do if I can get it to build. -- Tamara Schmitz SCC Team SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany HRB 36809, AG Nürnberg Geschäftsführer: Felix Imendörffer
пн, 11 янв. 2021 г. в 18:49, Tamara Schmitz <tschmitz@suse.de>:
On 06/01/2021 16:56, Matwey V. Kornilov wrote:
Another consideration. Does anybody know any research on what FS is the most friendly to SD cards?
I believe that would be FAT32 which is what the firmware is optimised for but of course not very useful for a root fs. F2FS is a flash optimised FS.
One thing that I found out is that a lot of SD card vendors explicitly have an expected start sector on SD cards. Internally SD card flash is segmented into 4MiB blocks or something like that. Hence most SD cards formatted so that the standard FAT32 partition starts at block 8192. The Official Raspian Images respect this too by placing the boot partition at sector 8192 (you can validate this with `fdisk -l /dev/mmcblk0`). This could make a difference in performance.
This also may be important because some bootloader images are located before the first partition. For instance, u-boot.img is placed at 768 at beagle bone black. And currently only 655360 bytes are available for this image. It has already raised some booting bugs when u-boot.img didn't fit into this place and overwrote the first partition.
I tried to test this by building an image locally but failed due to some weird dependency issues. You should be achieve the alignment by changing the <type> tag in the .kiwi like `<type image="oem" disk_start_sector="8192">`
I would like to benchmark and compare multiple FS as well as the difference the alignment could do if I can get it to build.
-- Tamara Schmitz SCC Team SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany
HRB 36809, AG Nürnberg Geschäftsführer: Felix Imendörffer
-- With best regards, Matwey V. Kornilov
Hi Matwey,
Currently, half of JeOS images are supplied with ext4 and the other half - btrfs. And frankly speaking, I cannot figure out the rule why some specific board receives JeOS with ext4 instead of btrfs or vice-versa.
The idea is to move to btrfs if the particular device supports that filesystem as root device. Note however that btrfs is particularly unstable on aarch64, so it isn't a particularly great choice to use, but hopefully those issues will get fixed in the future by the filesystem team.
I suppose this was related somehow to btrfs support in u-boot, right?
Yes, ext4 is/was the historic choice (have something that works, similar to how android works).
Another consideration. Does anybody know any research on what FS is the most friendly to SD cards?
I am not aware of such research, but I would guess F2FS is very high on the list. btrfs is slightly better than ext4 in that regard. Typically it helps here to follow the Android lead (they switched from ext4 to F2FS years ago). Greetings, Dirk
participants (5)
-
Dirk Müller -
Matthias G. Eckermann -
Matwey V. Kornilov -
Per Jessen -
Tamara Schmitz