On Sat, Jun 27, 2020 at 8:05 PM Stasiek Michalski <stas...@michalski.cc> wrote:
> Yeah, some mistakes were made when handling the root size, some other
> issues with openQA when trying to fix it, Richard Brown had fun couple
> of weeks with that stuff, but it was all worth the effort. We didn't
> change much with how aggressively everything is snapshotted, because in
> practice, since most desktop updates are done on live systems (obviously
> excluding ro filesystems with transactional/atomic updates), everything
> can go wrong, both pre and post the  transaction, so every snapshot
> might be the one you need

Can you elaborate on the sorts of reasons you'd need the pre rolled
back versus the post? I imagine one is more common to use as a
rollback than the other.

> > Agreed. What do you think are the biggest remaining issues you have
> > with btrfs? Or even not directly btrfs, but side effects that are
> > still unresolved? Any desktop integration issues that stand out in
> > particular?
> There is no gui for basically anything btrfs related anywhere, since
> SUSE has had close to 0 interest in desktop for around 10 years. Since I
> heard there is nobody maintaining gnome-disk-utility, I might have some
> motivation to help out with it, since I am a huge fan of it, so we will
> see how much time I have over the coming weeks to implement things
> there. We wouldn't want it to die like banshee, would we?

That would be cool. There are some notes about this in the tracker for
the proposal we're using, #153. In particular when I think of the
layout (open)SUSE is using, I'd think you probably don't want to show
all subvolumes in this interface, let alone subvolume snapshots (many
of those on an (open)SUSE system!)

Chris Murphy
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to