[Pkg-raspi-maintainers] Building an image of Debian for Raspberry Pi 3

Michael Stapelberg stapelberg at debian.org
Thu Apr 26 15:39:16 BST 2018


On Thu, Apr 26, 2018 at 4:29 PM, Ludovic Brenta <ludovic at ludovic-brenta.org>
wrote:

> On Thu, 26 Apr 2018 16:06:17 +0200, Michael Stapelberg wrote:
>
>> - ext2 instead of ext4 for the root partition (SD cards are slow
>>>   and do not need a journalling file system which would only slow
>>>   them down even more, I think).
>>>
>>
>> Do you have any benchmarks/measurements supporting this claim? This
>> is the first time I hear about it.
>>
>
> I have no benchmarks but I know that a journal must be written to
> *in addition to* the regular file data and meta-data.  This not only
> uses additional bandwidth (which is not normally noticeable on a
> 6 Gbit/s link like SATA-3 but may be on USB 2.0 or SD card) but also
> creates a hot-spot on the device containing the journal (and this is
> probably bad for low-end devices like an SD card).


https://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime/
is somewhat dated, but looks credible (tytso is the lead developer of the
ext* series of file systems). I wouldn’t be too worried about the extra
bandwidth, especially as the trade-off is between fast, but easily corrupt
and slower, but robust.

https://www.raspberrypi.org/forums/viewtopic.php?t=142626 talks about wear
leveling (which addresses your hotspot concern).

In summary, I think using ext4 on any but the cheapest no-name SD cards
should be fine for the majority of our users.


>
>
> The other change is that python3.6-minimal has been upgraded from
>>> 3.6.4-3 in your latest image to 3.6.5~rc1-1 (testing) and 3.6.5-3
>>> (unstable).  And this package is giving me the following
>>> headache:
>>>
>>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>>>
>>> while executing the post-installation script of python3.6-minimal.
>>> As a consequence, all subsequent invocations of apt install will
>>> also fail as they notice the package is unconfigured and
>>> re-execute
>>> the postinst script.
>>>
>>> I think this may be due to the lack of support for threading in
>>> qemu, combined with the use of pipes in the postinst script.
>>>
>>
>> I would be surprised if qemu did not support threading. Have you
>> searched for bug reports about this symptom?
>>
>
> Yes and I found these:
> http://qemu.11.n7.nabble.com/Uncaught-target-signal-11-Segme
> ntation-fault-core-dumped-tp290467p290775.html
> https://stackoverflow.com/questions/15086238/error-qemu-unca
> ught-target-signal-11-segmentation-fault
>
> but I realize thay they may be outdated now. I was also led to
> understand that qemu did not support threading for ~10 years,
> maybe this has finally been implemented since.
>
> Also, no bug reports specifically for my problem.  And I am not
> yet certain this is a bug so I wanted to ask you before I filed one.
>
> --
> Ludovic Brenta.
>
>


-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-raspi-maintainers/attachments/20180426/a34ebbff/attachment.html>


More information about the Pkg-raspi-maintainers mailing list