From: Phillip Lougher <phillip.lougher@gmail.com>
To: 921146@bugs.debian.org
Cc: hartmans@debian.org, debian-ctte@lists.debian.org,
"László Böszörményi (GCS)" <gcs@debian.org>,
"Alexander Couzens" <lynxis@fe80.eu>,
linux-fsdevel@vger.kernel.org,
linux-embedded <linux-embedded@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Bug#921146: Program mksquashfs from squashfs-tools 1:4.3-11 does not make use all CPU cores
Date: Thu, 1 Aug 2019 16:23:33 +0100 [thread overview]
Message-ID: <CAB3wodfF=Gc3FbKedU4JBWi8hZLxcBPUtVPipsCVnaHdFXGk8Q@mail.gmail.com> (raw)
On Wed, 31 Jul 2019 17:43:44 +0200 Alexander Couzens <lynxis@fe80.eu> wrote:
> Hi L치szl칩,
>
> > On Wed, Jul 31, 2019 at 3:06 AM Steven Shiau <steven@nchc.org.tw>
> > wrote: [...]
> > As mentioned in the past, it's the
> > 0016-remove-frag_deflator_thread.patch that needs either reverted or
> > fixed by it's original author, Alexander Couzens (added to this mail).
>
> Since I've full weeks ahead, I can not make any estimation when
> I've time to look onto the performance issue.
>
That patch is a laughable piece of rubbish. I believe both you
people (the Debian maintainer and author) are in total denial
about your incompetence in this matter. This is obviously just my
opinion I've formed over the last couple of months, in case you want to
claim that it is libellous.
It is, obvious, from the patch where the problem lies. You *remove*
the parallel fragment compressor threads, and move the work onto the
main thread.
Now what do you think that does? It completely removes a significant
amount of the parallelism of Mksquashfs and makes the main thread
a bottleneck.
This is your fault and your problem, and it lies in your lack of
understanding.
Yet you continually blame your inability to make Mksquashfs work
correctly on *my* code being old and unmaintained and badly written.
This can be seen from the following excerpt from a post in this
Debian bug thread made by the Debian maintainer.
"> First of all, as squashfs-tools wasn't written in the last years, when
> reproducible builds became more famous. So it's not written
> with reproducible building in mind.
> For me is reproducible builds more important than using all cpu cores.
> But I don't use it with gigabytes images.
Yeah, it's quite an old software without real development in the recent years."
and
" This sounds more complex work than it can be achieved in this week.
Maybe a complete rewrite would be better then on the long run."
Constantly pointing the blame at my tools and my code.
This is typical of the poor worker who chooses to blame everyone
else but himself.
None of that is the case. 50% of the code-base of Squashfs-tools
was (re-)written in the last 9 years as part of on-going improvements.
It has also been maintained across that period.
As for your specific claim that Mksquashfs can't be made to produce
reproducible builds because it is old and written before reproducible
builds became popular. That is abject nonsense.
I added reproducible builds to Mksquashfs. It took one weekend.
https://github.com/plougher/squashfs-tools/commit/24da0c63c80be64e1adc3f24c27459ebe18a19af
> > > Or shall we gradually switch to squashfs-tools-ng is the upstream
> > > is more active:
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931965
> > It's under investigation. I'm traveling and will only arrive back
> > home on Sunday evening. Expect more details on this next week.
>
> I also seen the upcoming squashfs-tools-ng rising and quite interested
> to test it and reading the code.
> Depending on tests & the code, I could imagine I'll put my effort and
> time towards squashfs-tools-ng.
>
> @L치szl칩 It should be your call to revert or not. For sure there are
> also downstream users who need reproducible builds (e.g. tails) who
> may also change to squashfs-tools-ng if -ng is the only reproducible
> squashfs generator in debian.
>
Upstream Squashfs-tools now produces reproducible builds.
Squashfs-tools-ng, this is a rogue project masquerading as an
official new upstream . It is neither official nor a new upstream. As
Squashfs author and maintainer I completely disassociate that project
with the Squashfs project.
I also have publicly stated that this project is spreading falsehoods and
that it is defamatory to me as the Squashfs author and maintainer.
See:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931965#29
and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931965#34
I have lived for a couple of months with you two people bad-mouthing
Squashfs tools, it's code-base and my maintenance.
I have absolutely had enough.
I have CC'd this to the Debian project leader and the Debian technical
commitee, and also to linux-kernel, linux-fsdevel and linux-embedded
for wider attention.
What else do I have to do to make you stop bad-mouthing Squashfs? Sue?
Yours
Dr. Phillip Lougher
> Hopefully I'll find time to look into it.
>
> Best Regards,
> lynxis
> --
> Alexander Couzens
>
> mail: lynxis@fe80.eu
> jabber: lynxis@fe80.eu
> gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604
next reply other threads:[~2019-08-01 15:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <54a35258-081a-71cc-ef1b-9fffcf5e7f9f@nchc.org.tw>
2019-08-01 15:23 ` Phillip Lougher [this message]
2019-08-01 22:41 ` Bug#921146: Program mksquashfs from squashfs-tools 1:4.3-11 does not make use all CPU cores László Böszörményi (GCS)
2019-08-02 4:17 ` Phillip Lougher
[not found] ` <20190801222613.iugdsswxbn2pawgd@qor.donarmstrong.com>
2019-08-01 22:41 ` Phillip Lougher
2019-08-02 0:34 ` Theodore Y. Ts'o
2019-08-02 6:50 ` Phillip Lougher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAB3wodfF=Gc3FbKedU4JBWi8hZLxcBPUtVPipsCVnaHdFXGk8Q@mail.gmail.com' \
--to=phillip.lougher@gmail.com \
--cc=921146@bugs.debian.org \
--cc=debian-ctte@lists.debian.org \
--cc=gcs@debian.org \
--cc=hartmans@debian.org \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lynxis@fe80.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).