[opensuse-arm] Leap 15.2 image
Hi, I played with the Leap 15.2 image (build 98.3) this weekend. I used a SD card with an older installation on, so I could use the method described in https://en.opensuse.org/ HCL:Raspberry_Pi3#USB_key_installation_method Step 9 for boot from USB-stick. Is there any mean to boot from USB stick if no or an empty SD card is present? Except that I feel that one should not use btrfs on a 32GB SD card the installation went smooth. I noticed that there is no LXQT-pattern offered - was this forgotten, or is it coming later? Thanks Axel -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hello Axel, On 2020-02-23 T 17:03 +0100 Axel Braun wrote:
Except that I feel that one should not use btrfs on a 32GB SD card
one of the reasons to use btrfs for the RPi image (I know that at least for SUSE Linux Enterprise) is that it is compressed and thus the low IO-throughput of the SD card interface is accelerated; assuming a compression rate for the OS part of more than 30%, the performance factor should be similar for reads and writes. Hope this helps. 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 -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hello mathias, Am Sonntag, 23. Februar 2020, 22:36:33 CET schrieb Matthias G. Eckermann:
On 2020-02-23 T 17:03 +0100 Axel Braun wrote:
Except that I feel that one should not use btrfs on a 32GB SD card
one of the reasons to use btrfs for the RPi image (I know that at least for SUSE Linux Enterprise) is that it is compressed and thus the low IO-throughput of the SD card interface is accelerated; assuming a compression rate for the OS part of more than 30%, the performance factor should be similar for reads and writes.
Thanks for the information! So the old rule (i remember some discussions on the factory mailing list from some time ago) that btrfs on less than 40GB is not recommended, is not valid any longer? Cheers Axel -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 24.02.20 um 11:41 schrieb Axel Braun:
So the old rule (i remember some discussions on the factory mailing list from some time ago) that btrfs on less than 40GB is not recommended, is not valid any longer?
On less than 100GB ;-) I would never dare to try btrfs on anything less than 100GB. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hello Axel, On 2020-02-24 T 11:41 +0100 Axel Braun wrote:
Am Sonntag, 23. Februar 2020, 22:36:33 CET schrieb Matthias G. Eckermann:
On 2020-02-23 T 17:03 +0100 Axel Braun wrote:
Except that I feel that one should not use btrfs on a 32GB SD card
one of the reasons to use btrfs for the RPi image (I know that at least for SUSE Linux Enterprise) is that it is compressed and thus the low IO-throughput of the SD card interface is accelerated; assuming a compression rate for the OS part of more than 30%, the performance factor should be similar for reads and writes.
Thanks for the information!
So the old rule (i remember some discussions on the factory mailing list from some time ago) that btrfs on less than 40GB is not recommended, is not valid any longer?
well. I would have never called this "40GiB" a "rule", but more a "recommendation" for a btrfs root filesystem *with* snapshots enabled, and this recommendation has a *lot* of safety buffer included. Mind that this heavily depends on the - distribution and - your personal way of applying updates. To add some details: * For a Tumbleweed with add-hoc updates enabled, I would rate 40 GiB the lower limit, indeed, better more, as you have a lot of change, thus lots of snapshots and lots of metadata. * For a Leap or SUSE Linux Enterprise with, let's say, planned weekly updates, you can easily work with a btrfs filesystem as small as twice the size of the OS installation, or for an extra buffer three times: MINIMAL_SIZE=$(( 3* $( du -msx / | cut -d'/' -f1) )) I personally run (all my) systems with a 32 GiB root filesystem with snapshots enabled, and the number of snapshots limited to 8 in total. That said, for a Raspberry Pi and an SD card, I would recommend to apply updates rather carefully and not in tumbleweed style, because the SD card might not like this too much:-/ Thus, a 32 GiB filesystem (with compression enabled this is equivalent to 42 GiB or more effectively) should be very comfortable. Hope this helps. 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 -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 24.02.20 um 12:55 schrieb Matthias G. Eckermann:
well. I would have never called this "40GiB" a "rule", but more a "recommendation" for a btrfs root filesystem *with* snapshots enabled, and this recommendation has a *lot* of safety buffer included.
No, it has not. It is the total recipe for disaster and downtime. Been there, fixed that. On SLES though, not on openSUSE.
Mind that this heavily depends on the - distribution and - your personal way of applying updates.
To add some details:
* For a Tumbleweed with add-hoc updates enabled, I would rate 40 GiB the lower limit, indeed, better more, as you have a lot of change, thus lots of snapshots and lots of metadata.
* For a Leap or SUSE Linux Enterprise with, let's say, planned weekly updates, you can easily work with a
nobody does this. The machine is installed, runs for a year or so, and then security comes around and urges for maintenance. The "update" of course contains a new service pack. Boom. No space left on device. Possible that this was with even lower default rootfs sizes in early SLES12, but still I would not use anything less than 100GB, because nobody can reliably predict what amount of storage will be lost to the dark gods of btrfs.
That said, for a Raspberry Pi and an SD card, I would recommend to apply updates rather carefully and not in tumbleweed style, because the SD card might not like this too much:-/ Thus, a
...coming back to topic of this ml... ;-) I have never seen a SD card die on my because of "too many writes", the wear leveling stuff seems to work good enough. I only use Sandisk (and nowadays Sandisk Extreme or Pro), though. I have only have them break mechanically (they do stick out of the board and thus can get broken mechanically) or have them killed by overvoltage spikes etc. Also the performance of my SD cards is good enough that I do not think that compression improves it much, and the cost of the btrfsmaintenance tasks would probably be pretty bad on raspi-grade hardware. So for me it's XFS, because I love my data and want to have it back ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Mon, Feb 24, Stefan Seyfried wrote:
Am 24.02.20 um 12:55 schrieb Matthias G. Eckermann:
well. I would have never called this "40GiB" a "rule", but more a "recommendation" for a btrfs root filesystem *with* snapshots enabled, and this recommendation has a *lot* of safety buffer included.
No, it has not. It is the total recipe for disaster and downtime. Been there, fixed that. On SLES though, not on openSUSE.
My machine is running since SLES12 SP2 with all updates to SLES12 SP3, SLES15 GA, SLES15 SP1 and never made any problems with that size.
Mind that this heavily depends on the - distribution and - your personal way of applying updates.
To add some details:
* For a Tumbleweed with add-hoc updates enabled, I would rate 40 GiB the lower limit, indeed, better more, as you have a lot of change, thus lots of snapshots and lots of metadata.
* For a Leap or SUSE Linux Enterprise with, let's say, planned weekly updates, you can easily work with a
nobody does this.
seife == nobody? Because our customers I spoke with last week told me something different, so nobody could not "nobody in this world".
The machine is installed, runs for a year or so, and then security comes around and urges for maintenance. The "update" of course contains a new service pack.
Boom. No space left on device.
Of course, if you never update your machine and then apply a SP once in a year, the space requirements are much higher. But luckily, nobody is doing that ;)
I have never seen a SD card die on my because of "too many writes", the wear leveling stuff seems to work good enough. I only use Sandisk (and nowadays Sandisk Extreme or Pro), though. I have only have them break mechanically (they do stick out of the board and thus can get broken mechanically) or have them killed by overvoltage spikes etc.
We have four of this expensive cards broken from our Raspberry Pi 3 cluster ... Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Mon, Feb 24, 2020 at 12:55:05PM +0100, Matthias G. Eckermann wrote:
Hello Axel,
On 2020-02-24 T 11:41 +0100 Axel Braun wrote:
Am Sonntag, 23. Februar 2020, 22:36:33 CET schrieb Matthias G. Eckermann:
On 2020-02-23 T 17:03 +0100 Axel Braun wrote:
Except that I feel that one should not use btrfs on a 32GB SD card
one of the reasons to use btrfs for the RPi image (I know that at least for SUSE Linux Enterprise) is that it is compressed and thus the low IO-throughput of the SD card interface is accelerated; assuming a compression rate for the OS part of more than 30%, the performance factor should be similar for reads and writes.
Thanks for the information!
So the old rule (i remember some discussions on the factory mailing list from some time ago) that btrfs on less than 40GB is not recommended, is not valid any longer?
well. I would have never called this "40GiB" a "rule", but more a "recommendation" for a btrfs root filesystem *with* snapshots enabled, and this recommendation has a *lot* of safety buffer included.
Mind that this heavily depends on the - distribution and - your personal way of applying updates.
To add some details:
* For a Tumbleweed with add-hoc updates enabled, I would rate 40 GiB the lower limit, indeed, better more, as you have a lot of change, thus lots of snapshots and lots of metadata.
* For a Leap or SUSE Linux Enterprise with, let's say, planned weekly updates, you can easily work with a btrfs filesystem as small as twice the size of the OS installation, or for an extra buffer three times:
MINIMAL_SIZE=$(( 3* $( du -msx / | cut -d'/' -f1) ))
I personally run (all my) systems with a 32 GiB root filesystem with snapshots enabled, and the number of snapshots limited to 8 in total.
That said, for a Raspberry Pi and an SD card, I would recommend to apply updates rather carefully and not in tumbleweed style, because the SD card might not like this too much:-/ Thus, a 32 GiB filesystem (with compression enabled this is equivalent to 42 GiB or more effectively) should be very comfortable.
To move even closer to a real sytem: I'm running btrfs on 12GB https://build.opensuse.org/package/show/home:duwe:Teres-I/Teres-I-image without snapshotting, and it "works". In quotes because I have not done comparisons or even benchmarks vs. f2fs or ext4. Torsten -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Mon, Feb 24, Axel Braun wrote:
So the old rule (i remember some discussions on the factory mailing list from some time ago) that btrfs on less than 40GB is not recommended, is not valid any longer?
This rule was for the root filesystem of SLES/Tumbleweed with snapshots enabled. If you look at other "products" like JeOS or MicroOS, you would have noticed that they don't follow this "rule", as they don't match the specification for this rule. Never quote anything out of the context. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (6)
-
Axel Braun -
Axel Braun
-
Matthias G. Eckermann -
Stefan Seyfried -
Thorsten Kukuk -
Torsten Duwe