On Sat, Aug 1, 2020 at 6:43 AM Artem Tim wrote:
>
> @Chris, thanks, i did some tests and now we have some numbers. tl;rd the
> results is pretty satisfying me, even if there no speedup in my case, but
> there is a lot disk space could be saved and reduce writes. Probably not
> worth file a
@Chris, thanks, i did some tests and now we have some numbers. tl;rd the
results is pretty satisfying me, even if there no speedup in my case, but there
is a lot disk space could be saved and reduce writes. Probably not worth file a
bug, but a little bit weird that with zstd:1 still a little
On 7/10/20 1:56 AM, Nicolas Mailhot via devel wrote:
Le jeudi 09 juillet 2020 à 23:47 +, Zachary Lym a écrit :
Yes, it's completely reasonable to not do it. It might seem like a
big
change on its own, but Btrfs has had native compression for 10+
years,
and at least three years for most all
On Wed, Jul 29, 2020 at 2:59 PM Artem Tim wrote:
>
> I am experimenting now with various compression in Fedora and noticed
> slowdowns with compression only for mock at this moment. On 4-core CPU
> building in mock with zstd:1 on HDD is slower. Also 'autodefrag' and
> 'space_cache=v2' options
On Wed, Jul 29, 2020 at 2:59 PM Artem Tim wrote:
>
> I am experimenting now with various compression in Fedora and noticed
> slowdowns with compression only for mock at this moment. On 4-core CPU
> building in mock with zstd:1 on HDD is slower. Also 'autodefrag' and
> 'space_cache=v2' options
I am experimenting now with various compression in Fedora and noticed slowdowns
with compression only for mock at this moment. On 4-core CPU building in mock
with zstd:1 on HDD is slower. Also 'autodefrag' and 'space_cache=v2' options
enabled on HDD.
> https://paste.centos.org/view/f4165396
>
> Two workloads: install and update. It might seem like an update is
> both read and write dependent, but the rpms are already compressed and
> don't get compressed again. The differences, I expect, are mostly
> write performance. And this suggests it's
Maybe Workstation could provide Déjà Dup in the default system to make
it discoverable and encourage users to create backups.
It has to be an installed application (can’t be a website), and most
users would benefit from having backups.
___
devel mailing
On Fri, Jul 10, 2020, 8:37 AM Matthew Miller
wrote:
> On Fri, Jul 10, 2020 at 12:59:37AM -0600, Chris Murphy wrote:
> > https://paste.centos.org/view/f4165396
> >
> > Two workloads: install and update. It might seem like an update is
> > both read and write dependent, but the rpms are already
On Fri, Jul 10, 2020 at 12:59:37AM -0600, Chris Murphy wrote:
> https://paste.centos.org/view/f4165396
>
> Two workloads: install and update. It might seem like an update is
> both read and write dependent, but the rpms are already compressed and
> don't get compressed again. The differences, I
Le jeudi 09 juillet 2020 à 23:47 +, Zachary Lym a écrit :
> > Yes, it's completely reasonable to not do it. It might seem like a
> > big
> > change on its own, but Btrfs has had native compression for 10+
> > years,
> > and at least three years for most all of the workloads at Facebook.
> > So
On Wed, Jul 8, 2020 at 9:50 AM Matthew Miller wrote:
>
> More data is always better. I like qualifying the situations in that way. I
> think we should make our decision based on the "center" rather than the
> edges, though.
>
> For I hope obvious reasons, I'd love to see this tested on a Lenovo
On Friday, July 10, 2020, Zachary Lym wrote:
> > Yes, it's completely reasonable to not do it. It might seem like a big
> > change on its own, but Btrfs has had native compression for 10+ years,
> > and at least three years for most all of the workloads at Facebook. So
> > it's quite safe.
>
>
> Yes, it's completely reasonable to not do it. It might seem like a big
> change on its own, but Btrfs has had native compression for 10+ years,
> and at least three years for most all of the workloads at Facebook. So
> it's quite safe.
But it has been eating data as recently as 2018 [1] and the
On Wed, Jul 08, 2020 at 02:20:06PM -0700, John M. Harris Jr wrote:
> > Yeah I guess for /usr the most relevant write metric is "does it slow down
> > DNF upgrades or install operations enough to be noticeable / annoying /
> > problematic"?
> More importantly, does it hurt the performance of
On Wednesday, July 8, 2020 10:20:30 AM MST Matthew Miller wrote:
> On Wed, Jul 08, 2020 at 11:08:53AM -0600, Chris Murphy wrote:
>
> > I expect beefy CPU systems, including gaming systems, to have the same
> > or better read/write performance using mount option compress=zstd:1.
> > Where I've
On Wed, Jul 8, 2020 at 12:54 PM Adam Williamson
wrote:
>
> On Wed, 2020-07-08 at 00:24 -0600, Chris Murphy wrote:
> > Hi,
> >
> > The change proposal has a 'compression option' and we kinda need to
> > get organized.
> > https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Compression
>
> It
On Wed, Jul 8, 2020 at 1:45 PM Matthew Miller wrote:
>
> On Wed, Jul 08, 2020 at 11:37:11AM -0600, Chris Murphy wrote:
> > If it's the center, I think that favors the mount option approach and
> > do it with the lowest level of compression, i.e. zstd:1. But this
> > suggests more benchmarking
On Wed, Jul 08, 2020 at 11:37:11AM -0600, Chris Murphy wrote:
> If it's the center, I think that favors the mount option approach and
> do it with the lowest level of compression, i.e. zstd:1. But this
> suggests more benchmarking still, to make certain it's well understood
> what the range of
It feels to me like this might be a great area to slow down a bit and
not try to do everything at once.
Why don't we just make the simplest change for F33 - going to btrfs by
default - and see how that goes, and consider the 'options' for F34 or
later, rather than changing too much stuff at
On Wed, 2020-07-08 at 00:24 -0600, Chris Murphy wrote:
> Hi,
>
> The change proposal has a 'compression option' and we kinda need to
> get organized.
> https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Compression
It feels to me like this might be a great area to slow down a bit and
not try
On Wed, Jul 8, 2020 at 11:20 AM Matthew Miller wrote:
>
> On Wed, Jul 08, 2020 at 11:08:53AM -0600, Chris Murphy wrote:
> > I expect beefy CPU systems, including gaming systems, to have the same
> > or better read/write performance using mount option compress=zstd:1.
> > Where I've seen equal or
On Wed, Jul 8, 2020 at 1:20 PM Matthew Miller wrote:
>
> On Wed, Jul 08, 2020 at 11:08:53AM -0600, Chris Murphy wrote:
> > I expect beefy CPU systems, including gaming systems, to have the same
> > or better read/write performance using mount option compress=zstd:1.
> > Where I've seen equal or
On Wed, Jul 8, 2020 at 10:54 AM Mark Pearson wrote:
>
> I personally haven't had any experience with btrfs but if there are any
> guidelines on testing that we can do and what data should be collected to
> help out let me know and I'll see if we can hit up some of our platforms and
> get some
On Wed, Jul 8, 2020 at 9:50 AM Matthew Miller wrote:
>
> On Wed, Jul 08, 2020 at 12:24:27AM -0600, Chris Murphy wrote:
> > 2. Benchmarking: this is hard. A simple tool for doing comparisons
> > among algorithms on a specific bit of hardware is lzbench.
> > https://github.com/inikep/lzbench
> >
On Wed, Jul 08, 2020 at 11:08:53AM -0600, Chris Murphy wrote:
> I expect beefy CPU systems, including gaming systems, to have the same
> or better read/write performance using mount option compress=zstd:1.
> Where I've seen equal or better read performance, there can be a write
> performance drop
On Wed, Jul 8, 2020 at 5:13 AM Kamil Paral wrote:
>
> On Wed, Jul 8, 2020 at 11:22 AM Dominique Martinet
> wrote:
>>
>> Please test, but if a file is deemed not compressible (based on, not
>> sure what? the first few blocks?) then it will be stored in the
>> non-compressed version.
>> You can
> -Original Message-
> From: Matthew Miller
> Sent: Wednesday, July 8, 2020 11:51 AM
>
> On Wed, Jul 08, 2020 at 12:24:27AM -0600, Chris Murphy wrote:
> > 2. Benchmarking: this is hard. A simple tool for doing comparisons
> > among algorithms on a specific bit of hardware is lzbench.
> >
On Wed, Jul 08, 2020 at 12:24:27AM -0600, Chris Murphy wrote:
> 2. Benchmarking: this is hard. A simple tool for doing comparisons
> among algorithms on a specific bit of hardware is lzbench.
> https://github.com/inikep/lzbench
> How to compile on F32.
> https://github.com/inikep/lzbench/issues/69
On Wednesday, July 8, 2020 1:10:12 AM MST Kamil Paral wrote:
> On Wed, Jul 8, 2020 at 8:26 AM Chris Murphy wrote:
> > D. Which directories? Some may be outside of the installer's scope.
> >
> > /usr
> > /var/lib/flatpak
> > ~/.local/share/flatpak
>
> I have a concern regarding games. Currently,
On Wed, Jul 8, 2020 at 11:22 AM Dominique Martinet
wrote:
> Please test, but if a file is deemed not compressible (based on, not
> sure what? the first few blocks?) then it will be stored in the
> non-compressed version.
> You can check with compsize after the fact if the file had been
>
Kamil Paral wrote on Wed, Jul 08, 2020:
> On Wed, Jul 8, 2020 at 8:26 AM Chris Murphy wrote:
>
> > D. Which directories? Some may be outside of the installer's scope.
> >
> > /usr
> > /var/lib/flatpak
> > ~/.local/share/flatpak
>
> I have a concern regarding games. Currently, we have a few a
On Wed, Jul 8, 2020 at 8:26 AM Chris Murphy wrote:
> D. Which directories? Some may be outside of the installer's scope.
>
> /usr
> /var/lib/flatpak
> ~/.local/share/flatpak
>
I have a concern regarding games. Currently, we have a few a bit more
demanding titles on Flathub already, like 0AD,
Hi,
The change proposal has a 'compression option' and we kinda need to
get organized.
https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Compression
- Compression saves space, significantly reduces write amplification
and therefore increases flash lifespan, and in some cases increases
34 matches
Mail list logo
