On Sat, Jun 27, 2020 at 8:05 PM Stasiek Michalski <stasiek(a)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