Re: btrfs compression by default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jiří, Vendula, all,

On Tue, 2021-02-09 at 12:12 +0100, Vendula Poncova wrote:
> On Tue, Feb 9, 2021 at 10:42 AM <jkonecny@xxxxxxxxxx> wrote:
> > 
> > Hi everyone,
> > 
> > I see a few options for this. First is to add this directly to
> > blivet
> > library as you pointed out already. However, I don't think blivet
> > developers would be happy about that because they are trying to be
> > as
> > much as possible general purpose library and this change is really
> > just
> > about Anaconda.
> > 
> > Another option seems to be to modify Anaconda code directly.
> > Unfortunately, I can't tell from top of my mind how hard that would
> > be
> > but still seems like the easiest solution.
> > 
> > However, the best approach which I can think of is to add something
> > like that to our configuration files. Benefit would be that another
> > modifications like that could be done easily in the future. That is
> > of
> > course for a discussion for the Anaconda team because it could be
> > pretty hard to implemented this in some common form.
> > 
> > Vendy, Vojta, do you have some better ideas or could you tell us
> > something more about my ideas above?
> > 
> > Best Regards,
> > Jirka
> > 
> > On Tue, 2021-02-09 at 01:18 -0500, Neal Gompa wrote:
> > > On Tue, Feb 9, 2021 at 1:09 AM Michel Alexandre Salim
> > > <michel@xxxxxxxxxxxxxxx> wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > On Mon, 2021-02-08 at 21:02 -0700, Chris Murphy wrote:
> > > > > Hi,
> > > > > 
> > > > > This is in regards to this Fedora 34 change:
> > > > > https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression#Scope
> > > > > 
> > > > > The gist is to do 'mount -o compress=zstd:1' anytime Btrfs is
> > > > > used,
> > > > > whether Destination Installation>Automatic or Custom or
> > > > > Advanced-Custom. Apply it during the installation, and add it
> > > > > to
> > > > > /etc/fstab.
> > > > > 
> > > > > Somehow I got confused thinking that autopart supports --
> > > > > fsoptions,
> > > > > and that would be the way to do this. But (a) --fsoptions
> > > > > isn't
> > > > > supported with autopart, and (b) it wouldn't be a universal
> > > > > approach
> > > > > anyway. And we want this to be consistent. Now I'm thinking
> > > > > it
> > > > > needs
> > > > > to go somewhere in:
> > > > > 
> > > > > https://github.com/storaged-project/blivet/blob/3.4-devel/blivet/devices/btrfs.py
> > > > > 
> > > > > Am I on the right track, or does it need to go somewhere
> > > > > else, or
> > > > > in
> > > > > addition to that?
> > > > > 
> > > > (I'm one of the change owners, and trying to figure this out
> > > > with
> > > > Chris).
> > > > 
> > > > Ideally we have a solution that is configurable - i.e. this is
> > > > exposed
> > > > via a kickstart command (and probably entailing changes in
> > > > Anaconda
> > > > and
> > > > pykickstart), but if that is not possible, or require a lot of
> > > > rework
> > > > (which we can try to work on), if we are willing to carry a
> > > > patch
> > > > for
> > > > blivet or some other component to override the behavior just
> > > > for
> > > > Fedora
> > > > 34, what's the best way of achieving that?
> > > > 
> > > > Btrfs is probably the only filesystem with built-in compression
> > > > that we
> > > > potentially care about, so designing an interface to expose
> > > > this
> > > > functionality might be an overkill -- but we're not sure.
> > > > 
> > > 
> > > Eventually, VDO might get integrated into the mainline tree, so
> > > having
> > > the interface which could be used for LVM compression through VDO
> > > wouldn't be too bad.
> > > 
> > > 
> > > 
> > 
> > 
> 
> Hello!
> 
> The change says: "On variants using btrfs as the default filesystem,
> enable transparent compression using zstd." It means that the
> compression has to be configurable per product, so we need to add a
> new configuration option to the Anaconda configuration files
> (something like btrfs_compression_enabled = True). I guess you
> planned
> to use interactive-defaults.ks, but we are going to replace this file
> with the configuration files anyway.
> 
> I have checked the Blivet's code and we might be able to redefine the
> _mount_class attribute of the BTRFS class. The mount class defines
> default mount options. That should be enough to fix all partitioning
> methods. What do you think, Vojta?
> 
> Vendy
> 
> _______________________________________________
> Anaconda-devel-list mailing list
> Anaconda-devel-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
> 

I took an initial stab at this -- would this be the way to achieve this
by overriding `_mount_class` in Blivet only?

https://github.com/storaged-project/blivet/pull/930 (for 3.4-devel)
https://github.com/storaged-project/blivet/pull/931 (for 3.3-devel)

Presumably this might be too specific to get merged upstream, but could
be something we can apply as patches against Fedora's python-blivet RPM
while we work out a more generic solution.

Vendula: is the more generic configuration mechanism supposed to work
like this?

- specify in an Anaconda config file that we want to override some
options (which file would this be?)
- if this flag is set, when Anaconda tells Blivet it wants a Btrfs
filesystem, override `_mount_class` (so the code for the new class can
live in Anaconda but subclasses a Blivet class)

There's a further complication: Chris just informed me that on BIOS
systems, space is more of a constraint so the zstd module is not part
of GRUB ... meaning we have to handle these two scenarios:

- if /boot is a directory on a / btrfs file system, we need to override
the compression property for it before any files get written there,
*or* defragment the files in %post
- if /boot is a separate btrfs file system, we need to make sure we
don't compress it so we might need to either use a separate
BTRFSBootMount class, or use the standard FSMount, but also somehow
prevent BTRFSMount to be used if the mount point is /boot

Oh what a tangled web we weave... thoughts on all this? And thanks for
the useful pointers,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/michel@xxxxxxxxxxxxxxx
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux