(a):
> > > > After a recent change in the build system (which I am not aware of),
> I
> > > > noticed that the generated RPM for the Tomcat package now has an
> unexpected
> > > > dependency:
> > > >
> > > > $ rpm -qp --re
I am not aware of), I
> > > noticed that the generated RPM for the Tomcat package now has an
> > > unexpected
> > > dependency:
> > >
> > > $ rpm -qp --requires tomcat-9.0.98-1.fc43.noarch.rpm
> > > ...
> > > *filesystem(unmerged-sbin-symlin
s an unexpected
> > dependency:
> >
> > $ rpm -qp --requires tomcat-9.0.98-1.fc43.noarch.rpm
> > ...
> > *filesystem(unmerged-sbin-symlinks)*
> > ...
> >
> > As a result, attempting to install the RPM fails with the following error:
> > Problem 1: conflictin
fc43.noarch.rpm
> ...
> *filesystem(unmerged-sbin-symlinks)*
> ...
>
> As a result, attempting to install the RPM fails with the following error:
> Problem 1: conflicting requests
> - nothing provides filesystem(unmerged-sbin-symlinks) needed by
> tomcat-1:9.0.98-1.fc43.noarch
Hi all,
After a recent change in the build system (which I am not aware of), I
noticed that the generated RPM for the Tomcat package now has an unexpected
dependency:
$ rpm -qp --requires tomcat-9.0.98-1.fc43.noarch.rpm
...
*filesystem(unmerged-sbin-symlinks)*
...
As a result, attempting to
[1].
> >
> > Sandro
> >
> > [1]
> > https://src.fedoraproject.org/rpms/mingw-filesystem/blob/rawhide/f/mingw.req
>
> I see, good point.
>
> There's a concern in this bug:
>
> > >https://src.fedoraproject.org/rpms/virt-v2v/pull-reque
On Wed, Aug 30, 2023 at 10:36:26AM +0200, Sandro Mani wrote:
> Hi
>
> I'd say, as least as it stands now, this is because the dependency
> generators require mingw-objdump, see mingw.req [1].
>
> Sandro
>
> [1]
> https://src.fedoraproject.org/rpms/mingw-filesy
Hi
I'd say, as least as it stands now, this is because the dependency
generators require mingw-objdump, see mingw.req [1].
Sandro
[1]
https://src.fedoraproject.org/rpms/mingw-filesystem/blob/rawhide/f/mingw.req
On 30.08.23 10:30, Richard W.M. Jones wrote:
https://src.fedoraprojec
https://src.fedoraproject.org/rpms/virt-v2v/pull-request/2
mingw-binutils-generic contains a random selection of binaries:
$ rpm -ql mingw-binutils-generic
/usr/bin/mingw-nm
/usr/bin/mingw-objcopy
/usr/bin/mingw-objdump
/usr/bin/mingw-strip
For unclear reasons, mingw32-filesystem depends on
Hi all,
lua-filesystem has not been properly updated since 2015; we missed the
1.7.0 release in 2017 and the 1.8.0 release in April last year.
The changelogs seem to indicate this should be backward-compatible, but
if your package depends on the `lfs` module please test:
F32 https
On Fri, Oct 2, 2020 at 9:10 AM Ben Cotton wrote:
>
> == How To Test ==
> The change could be tested by booting ISO images from the compose
> below. Regular Fedora test suite should be sufficient to verify this
> change.
> [https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200925.
https://fedoraproject.org/wiki/Changes/OptimizeSquashFSOnDVDByRemovingEXT4FilesystemImageLayer
== Summary ==
Change the process of building installation images such that the
Squash filesystem image, which is present on netinstall and DVD ISO
images, doesn't contain the EXT4 filesystem image.
Hello,
I filed another change proposal, which is related to the original one:
https://fedoraproject.org/wiki/Changes/OptimizeSquashFSOnDVDByRemovingEXT4FilesystemImageLayer
The new proposal does not change compression parameters of the SquashFS
image on DVD.
On 18/09/2020 12:54, Zbigniew Jęd
On Fri, Sep 18, 2020 at 09:31:59AM +0200, Bohdan Khomutskyi wrote:
> Hello Zbyszek,
>
> > You haven't really answered the "why" part: why is it so important to
> save 50MB? And why is the effect on QA less important?
>
> From my perspective, the storage on the installation medium should
> be effi
eady available data I
previously posted for Fedora Live images at
https://fedoraproject.org/wiki/Changes/OptimizeSquashFS
As a reminder, there are 2 levels for this optimization:
1. Making the SquashFS filesystem on the DVD plain (i.e. without
embedded EXT4 inside it) -- has the suffix plain-xz-
Gary Buhrmaster wrote:
> Some people download once, and install once. For
> those, it is pay me now, or pay me later, and it may
> be a wash, time wise, depending on your download
> speeds, but it is also just a one time thing in any
> case. Some people download once, and install lots
> of times
On Tue, Sep 15, 2020 at 11:47 PM Kevin Kofler wrote:
> There still exist connections as slow as 33 kbps.
And no doubt you can find people still using 300 baud
TI Silent 700 terminals. However, the global internet
speed tests show that the numbers are much higher
on average, and we should consid
On 9/15/20 4:46 PM, Kevin Kofler wrote:
There still exist connections as slow as 33 kbps. At that speed, 142 MB take
at least 10 hours to download (probably more because 1 data byte takes more
than 8 raw bits to transfer and because the theoretical speed cannot always
be sustained). Depending on
Frantisek Zatloukal wrote:
> Saving 142 MBs isn't going to make a huge difference in download times
> (disclaimer: I don't know how is the internet connection
> speed in other areas, I have not that fast connection of 200mbps down
> (slowest possible in my area), so 142 MB saving would make roughly
Kamil Paral wrote:
> Each image is downloaded just once, but installed 1+ times.
Most end users install the image exactly once.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@list
s/1tGsoqFMg2A6dQZHfuQNb9uDqYu9XEiPI
>
> The result of benchmark will supplement already available data I
> previously posted for Fedora Live images at
> https://fedoraproject.org/wiki/Changes/OptimizeSquashFS
>
> As a reminder, there are 2 levels for this optimization:
>
> 1.
https://fedoraproject.org/wiki/Changes/OptimizeSquashFS
As a reminder, there are 2 levels for this optimization:
1. Making the SquashFS filesystem on the DVD plain (i.e. without
embedded EXT4 inside it) -- has the suffix plain-xz-128k.iso
2. In addition to #1, using a different compression
oject.org/wiki/Changes/OptimizeSquashFS
>
> == Summary ==
> Improve compression ratio of SquashFS filesystem on the installation
> media.
>
...
>
> Based on the results above, I'd suggest selecting the following
> ''optimal configurati
On Thu, Aug 27, 2020 at 11:13:26AM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/OptimizeSquashFS
...
> Based on the results above, I'd suggest selecting the following
> ''optimal configuration'': XZ algorithm, with block size of 1MiB and
> without BCJ filter (plain xz -b 1M, wi
On Fri, Sep 4, 2020 at 6:17 AM John Reiser wrote:
> On 2020-09-01 at 12:13 UTC, Kamil Paral wrote:
> [[snip]]
> > I'd like to ... hugely speed up the installation instead
> [[snip]]
>
> Zstd is faster than xz at de-compression, but a much larger speed
> improvement
> would be to parallel
etc.) can be installed in parallel. Even for scriptlets that might force
serialization [such as selinux], all processing before the first Write-to-
destination-filesystem can be parallel. For any individual .rpm, the stages
of fetch the package (from network, USB flash memory, DVD, etc.), decompress,
On Thu, Sep 03, 2020 at 11:30:10AM +0200, Kamil Paral wrote:
> On Wed, Sep 2, 2020 at 8:28 PM Matthew Miller
> wrote:
>
> > On Tue, Sep 01, 2020 at 02:13:21PM +0200, Kamil Paral wrote:
> > > Bohdan, could you build the same image in several configurations (the
> > most
> > > likely candidates) an
On Wed, Sep 2, 2020 at 8:28 PM Matthew Miller
wrote:
> On Tue, Sep 01, 2020 at 02:13:21PM +0200, Kamil Paral wrote:
> > Bohdan, could you build the same image in several configurations (the
> most
> > likely candidates) and share them with us? (We can host them in our QA
> > fedorapeople space, i
On Tue, Sep 01, 2020 at 02:13:21PM +0200, Kamil Paral wrote:
> Bohdan, could you build the same image in several configurations (the most
> likely candidates) and share them with us? (We can host them in our QA
> fedorapeople space, if needed). That would allow interested parties to test
> and benc
On Tue, Sep 1, 2020 at 3:22 AM Frantisek Zatloukal wrote:
>
>
>
> On Thu, Aug 27, 2020 at 5:16 PM Ben Cotton wrote:
>>
>> https://fedoraproject.org/wiki/Changes/OptimizeSquashFS
>>
>> == Summary ==
>> Improve compression ratio of SquashFS filesystem
On Tue, Sep 1, 2020 at 5:23 AM Frantisek Zatloukal wrote:
>
> Saving 142 MBs isn't going to make a huge difference in download times
> (disclaimer: I don't know how is the internet connection speed in other
> areas, I have not that fast connection of 200mbps down (slowest possible in
> my area)
On Fri, Aug 28, 2020 at 12:55 AM Michel Alexandre Salim <
mic...@michel-slm.name> wrote:
> On Thu, 2020-08-27 at 11:13 -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/OptimizeSquashFS
> >
> > == Summary ==
> > Improve compression ra
On Thu, Aug 27, 2020 at 5:16 PM Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/OptimizeSquashFS
>
> == Summary ==
> Improve compression ratio of SquashFS filesystem on the installation media.
>
> == Owner ==
> * Name: [[User:bkhomuts|Bohdan Khomutskyi]]
> * Em
On Thu, 2020-08-27 at 11:13 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/OptimizeSquashFS
>
> == Summary ==
> Improve compression ratio of SquashFS filesystem on the installation
> media.
>
...
>
> Based on the results above, I'd suggest select
https://fedoraproject.org/wiki/Changes/OptimizeSquashFS
== Summary ==
Improve compression ratio of SquashFS filesystem on the installation media.
== Owner ==
* Name: [[User:bkhomuts|Bohdan Khomutskyi]]
* Email: bkhom...@redhat.com
== Detailed Description ==
As of Fedora 31, the LiveOS
results -- working proof of concept. With the
following change: https://github.com/rhinstaller/anaconda/pull/2292 ,
not only the higher compression does not impact the installation time.
In certain cases, the installation time is even reduced. This is
because of the fact the filesystem internal
On Thu, Aug 06, 2020 at 12:02:09PM -0400, Alex Scheel wrote:
> - Original Message -
> > From: "Stephen John Smoogen"
> > To: "Development discussions related to Fedora"
> >
> > Sent: Thursday, August 6, 2020 10:55:51 AM
> > Subject:
- Original Message -
> From: "Stephen John Smoogen"
> To: "Development discussions related to Fedora"
>
> Sent: Thursday, August 6, 2020 10:55:51 AM
> Subject: Re: Respinning rawhide images every filesystem update?
>
> On Thu
M
> > Subject: Re: Respinning rawhide images every filesystem update?
> >
> > On Thu, 6 Aug 2020 at 09:36, Alex Scheel wrote:
> > >
> > > I'm bumping this thread. This is still broken.
> > >
> >
> > Please open a ticket at
> > https://pa
- Original Message -
> From: "Stephen John Smoogen"
> To: "Development discussions related to Fedora"
> , asch...@redhat.com
> Sent: Thursday, August 6, 2020 9:55:17 AM
> Subject: Re: Respinning rawhide images every filesystem update?
>
> On Thu
'
> - Original Message -
> > From: "Alex Scheel"
> > To: "Development discussions related to Fedora"
> >
> > Sent: Monday, August 3, 2020 2:36:40 PM
> > Subject: Respinning rawhide images every filesystem update?
> >
>
I'm bumping this thread. This is still broken.
- Original Message -
> From: "Alex Scheel"
> To: "Development discussions related to Fedora"
>
> Sent: Monday, August 3, 2020 2:36:40 PM
> Subject: Respinning rawhide images every filesystem upda
On Mon, Aug 03, 2020 at 02:36:40PM -0400, Alex Scheel wrote:
> Hey list,
>
>
> How do Fedora rawhide images get respun? Every time filesystem updates,
They are rebuild in every rawhide nightly compose.
Here's the one from last night/this morning:
https://koji.fedoraproject.
Hey list,
How do Fedora rawhide images get respun? Every time filesystem updates,
it causes `dnf update` to fail in a podman container because filesystem
can't be updated in a container. We either need to make sure filesystem
updates cause rawhide containers to be rebuilt, or figure out h
ssion does not impact the installation time. In certain cases, the
> > installation time is even reduced. This is because of the fact the
> > filesystem internal structure aware process is used to install the system
> > from the SquashFS. The new process also allows for taking advanta
On Wed, May 13, 2020 at 13:32:19 +0200,
Bohdan Khomutskyi wrote:
For optimization of the SquashFS, I will work on requesting the
support of the required functionality in the Pungi compose build
software.
Note that squashfs-tools 4.4 just went into rawhide a couple of days ago.
By default
achieved outstanding
> results -- working proof of concept. With the following change:
> https://github.com/rhinstaller/anaconda/pull/2292 , not only the higher
> compression does not impact the installation time. In certain cases, the
> installation time is even reduced. This is b
eved
> outstanding results -- working proof of concept. With the following change:
> https://github.com/rhinstaller/anaconda/pull/2292 , not only the higher
> compression does not impact the installation time. In certain cases, the
> installation time is even reduced. This is becaus
: https://github.com/rhinstaller/anaconda/pull/2292 , not only the
higher compression does not impact the installation time. In certain
cases, the installation time is even reduced. This is because of the
fact the filesystem internal structure aware process is used to install
the system from the
lgorithm in EROFS, even if EROFS has perfect layout of the filesystem,
it's to good to be true it can outperform the XZ in compression ratio
tests. The difference for SquashFS LZ4hc 1M vs XZ 1M is >40%.
On Fri, Jan 24, 2020 at 2:17 AM Chris Murphy
wrote:
> On Mon, Jan 20, 2020 at
On Mon, Jan 20, 2020 at 1:38 AM Bohdan Khomutskyi wrote:
>
> In my previous message, I mentioned that CPU is underutilized during
> installation. I haven't investigated further why, but I suspect it's due to
> the inefficiency caused by the usage of the loop device and/or inefficiency
> in the
On Mon, Jan 20, 2020 at 1:38 AM Bohdan Khomutskyi wrote:
> In my previous message, I mentioned that CPU is underutilized during
> installation. I haven't investigated further why, but I suspect it's due to
> the inefficiency caused by the usage of the loop device and/or inefficiency
> in the r
On Sunday, January 19, 2020 4:41:06 PM MST Chris Murphy wrote:
> I admit I'm biased toward the two endpoints: create and consume, not
> distribution ,i.e the mirror donors. Their storage and bandwidth
> concerns were evaluated with the RPM change from xz to zstd. So I'm
> mystified by the bias for
page; it's not immediately
> clear *which of Fedora's images* are affected by this Change), but are
> you sure of this? Do we not do it even for Cloud image deployments or
> ARM disk image deployments? ISTR there being a filesystem resize
> involved there, which is why I ask...
On Sun, Jan 19, 2020 at 4:42 PM Bohdan Khomutskyi
wrote:
> Hello,
>
> Thanks everyone for posting feedback.
> More benchmarking results are available at
> https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS,
> including the 'plain' SquashFS filesystem.
ut are
you sure of this? Do we not do it even for Cloud image deployments or
ARM disk image deployments? ISTR there being a filesystem resize
involved there, which is why I ask...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: ada
On Mon, Jan 20, 2020 at 09:37:32AM +0100, Bohdan Khomutskyi wrote:
> Chris,
>
> Thanks for your feedback and comments, it's very valuable to me.
>
> In my previous message, I mentioned that CPU is *underutilized* during
> installation. I haven't investigated further why, but I suspect it's due to
On Sun, Jan 05, 2020 at 10:08:07AM -0700, Chris Murphy wrote:
> In my testing, xz does provide better compression ratios, well suited
> for seldom used images like archives. But it really makes the
> installation experience worse by soaking the CPU, times thousands of
> installations (openQA tests
for posting feedback.
> > More benchmarking results are available at
> https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS,
> including the 'plain' SquashFS filesystem.
> > After performing the tests, I personally recommend to use xz compression
> with 1MiB b
On Sun, Jan 19, 2020 at 8:41 AM Bohdan Khomutskyi wrote:
>
> Hello,
>
> Thanks everyone for posting feedback.
> More benchmarking results are available at
> https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS, including
> the 'plain' SquashFS fil
Hello,
Thanks everyone for posting feedback.
More benchmarking results are available at
https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS, including
the 'plain' SquashFS filesystem.
After performing the tests, I personally recommend to use xz compression
with 1MiB
On Sun, Jan 12, 2020 at 5:46 PM Bohdan Khomutskyi
wrote:
> Hello,
>
> I posted more benchmark results in this article:
> https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS
>
> In short, bigger block size and higher compression ratio does not increase
> the installation time for Fedo
On Sun, Jan 12, 2020 at 3:53 PM Samuel Sieb wrote:
>
> On 1/7/20 11:16 AM, Kevin Kofler wrote:
> > Chris Murphy wrote:
> >> Stacked images on the same media functionality is in the kernel, it's
> >> not complicated, it's well tested, doesn't require any gymnastics in
> >> the initramfs - your boot
On 1/7/20 11:16 AM, Kevin Kofler wrote:
Chris Murphy wrote:
Stacked images on the same media functionality is in the kernel, it's
not complicated, it's well tested, doesn't require any gymnastics in
the initramfs - your bootloader entries can each point to different
root=UUIDs and image assembly
On Sun, Jan 12, 2020 at 9:45 AM Bohdan Khomutskyi
wrote:
> Hello,
>
> I posted more benchmark results in this article:
> https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS
>
Cool!
Do you have any tests to compare plain squashfs xz with zstd? The nested
ext4 stuff is really pointle
On Sun, Jan 12, 2020 at 05:44:33PM +0100, Bohdan Khomutskyi wrote:
> Hello,
>
> I posted more benchmark results in this article:
> https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS
>
> In short, bigger block size and higher compression ratio does not increase
> the installation tim
Hello,
I posted more benchmark results in this article:
https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS
In short, bigger block size and higher compression ratio does not increase
the installation time for Fedora Workstation. I saw the opposite effect.
The Zstd compression perfor
Thanks everyone for your comments. These are all valid concerns.
I filed a new change proposal at
https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS.
I'll run more benchmarks, including using Zstd compression algorithm, and
will post results.
Hopefully this weekend, I'll also try to
>
> Why stacked images? Consider a single base.img that's maybe 1G, and
> now you don't have to do separate composes for server, cloud, GNOME,
> KDE, Cinnamon, LXQt, Astronomy that repeat a lot of the same steps,
> including expensive steps like compressing the same things over and
> over again. Ju
On Tue, 7 Jan 2020 at 18:07, Martin Kolman wrote:
> IIRC the speedups in compression and decompression
> speed we got for RPMs[0] with zstd were pretty nice
If it helps the argument, at the moment 99.7% of the time building the
AppStream metadata is spent decompressing the RPMs. If zstd helps wit
On Sun, Jan 5, 2020, at 12:08 PM, Chris Murphy wrote:
> I've pretty much concluded Fedora is best off dropping the nested ext4
> in favor of plain squashfs, and using zstd.
Fedora CoreOS already uses zstd for squashfs:
https://github.com/coreos/coreos-assembler/blob/master/src/cmd-buildextend-
e Fedora at all, because even the first dnf metadata update
will consume exactly this amount of data, and then they will be presented
with 1 GB worth of system updates.
Not to mention we're talking here about removing the nested ext4
filesystem, which is likely to *reduce* the image size (an
Chris Murphy wrote:
> Even at 8% bigger it would be worth it. And probably 16%.
I disagree. We need to stop treating bloat like a feature.
And please see my other replies for why this is a particularly bad tradeoff
in this particular case.
> Gaining additional features, like on the fly checksum
Gary Buhrmaster wrote:
> While not exactly the same, the measured increase in size
> by the Arch community for their packaging by moving from
> xz to zstd was ~0.8% (and gaining a huge reduction in CPU
> utilization at the decompress end).
I don't know what xz settings Arch was using, but in the c
Chris Murphy wrote:
> It's untenable to consider ISO size alone. It is a legitimate concern, but
> it can't be reasonable to soak every single CPU, times thousands. You're
> willing to exchange less download time for longer install time and higher
> energy demand, but there are quite a lot of othe
Brian C. Lane wrote:
> Yes, according to the manpage it supports xattrs.
Does that include file capabilities and ACLs?
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedorap
On Tue, Jan 07, 2020 at 09:56:21AM +0100, Kevin Kofler wrote:
> Brian C. Lane wrote:
> > I agree with Chris here, I think we should make the switch to plain
> > squashfs unless someone can come up something dramatic that it will
> > break :)
>
> Does SquashFS support all the advanced features that
On Tue, Jan 7, 2020 at 9:58 AM Gary Buhrmaster
wrote:
>
> On Tue, Jan 7, 2020 at 9:00 AM Kevin Kofler wrote:
>
> > I think increasing the size of the live images, also affecting the download
> > time and the time to write the image to media (even USB sticks are not
> > instant), to get a one-time
On Tue, 2020-01-07 at 11:20 -0700, Chris Murphy wrote:
> On Tue, Jan 7, 2020 at 11:07 AM Martin Kolman wrote:
> > On Mon, 2020-01-06 at 16:35 -0800, Brian C. Lane wrote:
> > > On Sun, Jan 05, 2020 at 10:08:07AM -0700, Chris Murphy wrote:
> > > > I've pretty much concluded Fedora is best off droppi
On Tue, Jan 7, 2020 at 11:07 AM Martin Kolman wrote:
>
> On Mon, 2020-01-06 at 16:35 -0800, Brian C. Lane wrote:
> > On Sun, Jan 05, 2020 at 10:08:07AM -0700, Chris Murphy wrote:
> > > I've pretty much concluded Fedora is best off dropping the nested ext4
> > > in favor of plain squashfs, and usin
On Mon, 2020-01-06 at 16:35 -0800, Brian C. Lane wrote:
> On Sun, Jan 05, 2020 at 10:08:07AM -0700, Chris Murphy wrote:
> > I've pretty much concluded Fedora is best off dropping the nested ext4
> > in favor of plain squashfs, and using zstd. It's not required to do
> > both, but the benefit is add
On Tue, Jan 7, 2020 at 9:00 AM Kevin Kofler wrote:
> I think increasing the size of the live images, also affecting the download
> time and the time to write the image to media (even USB sticks are not
> instant), to get a one-time installation speedup is a very bad tradeoff.
While not exactly t
It's untenable to consider ISO size alone. It is a legitimate concern, but it
can't be reasonable to soak every single CPU, times thousands. You're willing
to exchange less download time for longer install time and higher energy
demand, but there are quite a lot of other uses occurring that are
Kamil Paral wrote:
> Well for the general user, everything is one-time. One download, one write
> to USB, one install. Saving a minute in one step and adding it to a
> different step doesn't really matter, it's the same sum overall (unless
> you pay considerable money for the extra downloaded data,
On Tue, Jan 7, 2020 at 10:01 AM Kevin Kofler wrote:
> Chris Murphy wrote:
> > Has zstandard been evaluated? In my testing of images compressed with
> > zstd, the CPU hit is cut by more than 50%, and is no longer a
> > bottleneck during installations. Image size does increase, although I
> > haven
Chris Murphy wrote:
> Has zstandard been evaluated? In my testing of images compressed with
> zstd, the CPU hit is cut by more than 50%, and is no longer a
> bottleneck during installations. Image size does increase, although I
> haven't tested mksquashfs block size higher than 256K.
I think incre
Brian C. Lane wrote:
> I agree with Chris here, I think we should make the switch to plain
> squashfs unless someone can come up something dramatic that it will
> break :)
Does SquashFS support all the advanced features that are needed, such as
extended attributes (used at least by SELinux), file
On Sun, Jan 05, 2020 at 10:08:07AM -0700, Chris Murphy wrote:
> I've pretty much concluded Fedora is best off dropping the nested ext4
> in favor of plain squashfs, and using zstd. It's not required to do
> both, but the benefit is additive and significant. The work in dracut
> and lorax to support
On Sun, Jan 5, 2020 at 1:24 PM Bohdan Khomutskyi
wrote:
> Summary
>
> Improve compression ratio of SquashFS filesystem on the installation media.
>
Hi Bohdan, as a member of QA, I'll happily support any proposal that
improves the installation speed (the image size is not that
On Sun, Jan 5, 2020 at 7:24 AM Bohdan Khomutskyi wrote:
>
> I was unable to create an article in Fedora wiki system.
>
Since you don't have any non-CLA groups in FAS, I have added you to
the wikiedit group. Please add this to the wiki ASAP. This proposal is
past the deadline for Fedora 32 System-W
> Improve compression ratio of SquashFS filesystem on the installation
> media.
>
>
> Owner
>
> Name: Bohdan Khomutskyi
>
> Email: bkhom...@redhat.com <mailto:bkhom...@redhat.com>
>
>
> Current status
>
> Targeted release: I propose this change
On Sunday, January 5, 2020 5:23:12 AM MST Bohdan Khomutskyi wrote:
> Summary
>
> Improve compression ratio of SquashFS filesystem on the installation media.
> Owner
>
> Name: Bohdan Khomutskyi
>
> Email: bkhom...@redhat.com
> Current status
>
> Targeted r
On Sun, Jan 5, 2020 at 5:24 AM Bohdan Khomutskyi wrote:
>
> Summary
>
> Improve compression ratio of SquashFS filesystem on the installation media.
On the issues of Fedora ISOs using excessive CPU, related to lzma decompression:
https://bugzilla.redhat.com/show_bug.cgi?id=1
Summary
Improve compression ratio of SquashFS filesystem on the installation media.
Owner
Name: Bohdan Khomutskyi
Email: bkhom...@redhat.com
Current status
Targeted release: I propose this change for Fedora 32
Last updated: Jan 5 2020
Pagure.io issue: https://pagure.io/releng/issue/9127
I
Hi,
| When trying to mount a old SGI IRIX64 XFS filesystem, current Linux
| versions complain with:
| function not implemented
| So you have to use a older Linux version (e.g. 2.68).
Just for the records: i was able to read a IRIX64 XFS MO-dsik with a USB
MO-drive using
a Ubuntu Linux 4.10
On Sun, 17 Nov 2019 at 21:13, J. Scheurich wrote:
>
> Hi,
>
> When trying to mount a old SGI IRIX64 XFS filesystem, current Linux
> versions complain with:
>
There are going to be a bunch of problems trying to mount this
depending on how old the partition is:
https://xfs.org/i
On Sun, Nov 17, 2019 at 9:13 PM J. Scheurich wrote:
>
> Hi,
>
> When trying to mount a old SGI IRIX64 XFS filesystem, current Linux
> versions complain with:
>
> function not implemented
>
> So you have to use a older Linux version (e.g. 2.68).
>
> Which fedora
Hi,
When trying to mount a old SGI IRIX64 XFS filesystem, current Linux
versions complain with:
function not implemented
So you have to use a older Linux version (e.g. 2.68).
Which fedora version is old enough and are old fedora CD/DVD images
still available ?
so long
MUFTI
On 02/20/2018 05:40 PM, Zdenek Dohnal wrote:
> I want to have vim-filesystem subpackage as noarch (as most packages
> with *-filesystem subpackage have), but dir mentioned above is
> architecture specific, so I want to remove it.
>
> This dir was added in bugzilla #1193230 as dir
Zdenek Dohnal wrote:
> Hi,
>
> I want to have vim-filesystem subpackage as noarch (as most packages
> with *-filesystem subpackage have), but dir mentioned above is
> architecture specific, so I want to remove it.
>
> This dir was added in bugzilla #1193230 as dir for
1 - 100 of 414 matches
Mail list logo
