11:05 a.m.
I think if we really want to advocate for btrfs, we also should provide the
tools to take full advantage of it. I've been using btrfs since it was
offered as an option on Fedora. On Ubuntu, there is a tool "snapper" to
help manage snapshots. Unfortunately I didn't manage to get this setup on
Fedora. A tool like this would really enhance the btrfs experience, I
believe.
It's been a while, but I think the reason I didn't get snapper running on my
system is that the arrangement of btrfs subvolumes didn't match the default
ubuntu used. I have 2 subvolumes, 1 for root and 1 for home.
A primary use of snapshots would be to snapshot just before system update,
so update could easily be rolled back. This could also be helpful for large
updates within the user directory, for example, using pip to update
packages.
Thanks,
Neal
12:34 p.m.
On Sat, 2020-07-11 at 12:05 -0400, Neal Becker wrote:
I think if we really want to advocate for btrfs, we also should
provide the
tools to take full advantage of it. I've been using btrfs since it
was
offered as an option on Fedora. On Ubuntu, there is a tool "snapper"
to
help manage snapshots. Unfortunately I didn't manage to get this
setup on
Fedora. A tool like this would really enhance the btrfs experience,
I
believe.
That's certainly a good point; I believe this might be coming next if
the current Change proposal makes it to the final release, but we don't
want to to take on too many changes at once.
Some tools like snapper only need to be adapted, but if we want, e.g.,
good integration with desktop environments like GNOME and KDE, it might
be easier to make that investment knowing the filesystem is already the
new default and we're committed to keeping it the default.
I, for one, would like to see something like Timeslider for btrfs
(OpenSolaris Desktop / "Java" (sic) Desktop System used to have it) -
https://btrfs.wiki.kernel.org/index.php/Autosnap#Timeslider
Thanks,
--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2
6:39 a.m.
On Sat, 11 Jul 2020 at 18:05, Neal Becker <ndbecker2(a)gmail.com> wrote:
I think if we really want to advocate for btrfs, we also should
provide
the
tools to take full advantage of it. I've been using btrfs since it was
offered as an option on Fedora. On Ubuntu, there is a tool "snapper" to
help manage snapshots. Unfortunately I didn't manage to get this setup on
Fedora. A tool like this would really enhance the btrfs experience, I
believe.
It's been a while, but I think the reason I didn't get snapper running on
my
system is that the arrangement of btrfs subvolumes didn't match the
default
ubuntu used. I have 2 subvolumes, 1 for root and 1 for home.
I think it's a great idea and if it's possible to adapt Ubuntu's snapper or
OpenSUSE's solution
(afaik, they have it as a feature within YaST2 and snapshots are taken
prior to each update).
that would make our lives easier. A 1-click GNOME3 integration (through
Files, for instance?)
would be the icing on the cake.
A primary use of snapshots would be to snapshot just before system update,
so update could easily be rolled back. This could also be helpful for
large
updates within the user directory, for example, using pip to update
packages.
As mentioned above, the way OpenSUSE does it. However, I agree that
snapshots are
more useful when taken intentionally. On updates, a single automatic
corrupted snapshot can
potentially hose the entire snapshotted volume. Also, if your system is
almost broken after the change,
no snapshot will help.
Best,
Andy
11:07 a.m.
On Sun, Jul 12, 2020 at 5:39 AM Andy Mender <andymenderunix(a)gmail.com> wrote:
On updates, a single automatic corrupted snapshot can
potentially hose the entire snapshotted volume.
How do you mean? If this is a sort of superficial corruption like a
bad/failed/partial update, inconsistency between package manager and
what's installed - this can be self-contained to a specific snapshot.
One possible idea for updates is snapshot and do the update out of
band (not the current running sysroot) on a snapshot. If the update
fails for whatever reason, destroy the snapshot. Corruption that
affects multiple subvolumes wouldn't be related to snapshotting, but
the shared trees: extent, chunk, csum, uuid, etc. trees.
Also, if your system is almost broken after the change,
no snapshot will help.
I'm not sure about the nature of the brokenness in your example. Btrfs
does have a concept of a volume wide snapshot, which is the seed
device. The file system is merely marked read-only, but can have a
second device added that accepts all writes. If this two device volume
were to become irreversibly confused, it'd still be possible to revert
to the read-only device - even temporarily - as a kind of "recovery"
boot. With extreme prejudice, a true factory reset is possible by
wiping the read-write 2nd device and starting over. It's also possible
to use it for replication - by adding a 2nd device and removing the
1st, an exact copy is made. This is a whole separate ball of wax, and
while there are ideas how it might be leveraged, there's no plan to do
so yet.
--
Chris Murphy
1:50 p.m.
On Sun, 12 Jul 2020 at 18:09, Chris Murphy <lists(a)colorremedies.com> wrote:
On Sun, Jul 12, 2020 at 5:39 AM Andy Mender
<andymenderunix(a)gmail.com>
wrote:
>
>On updates, a single automatic corrupted snapshot can
> potentially hose the entire snapshotted volume.
How do you mean? If this is a sort of superficial corruption like a
bad/failed/partial update, inconsistency between package manager and
what's installed - this can be self-contained to a specific snapshot.
One possible idea for updates is snapshot and do the update out of
band (not the current running sysroot) on a snapshot. If the update
fails for whatever reason, destroy the snapshot. Corruption that
affects multiple subvolumes wouldn't be related to snapshotting, but
the shared trees: extent, chunk, csum, uuid, etc. trees.
I'm sorry, I should've been a little more specific. What I meant was that a
corrupted snapshot can potentially impact the subvolume and put it in a
state in which simply deleting the latest snapshot is not going to help or
can't easily be done.
>Also, if your system is almost broken after the change,
> no snapshot will help.
I'm not sure about the nature of the brokenness in your example. Btrfs
does have a concept of a volume wide snapshot, which is the seed
device. The file system is merely marked read-only, but can have a
second device added that accepts all writes. If this two device volume
were to become irreversibly confused, it'd still be possible to revert
to the read-only device - even temporarily - as a kind of "recovery"
boot. With extreme prejudice, a true factory reset is possible by
wiping the read-write 2nd device and starting over. It's also possible
to use it for replication - by adding a 2nd device and removing the
1st, an exact copy is made. This is a whole separate ball of wax, and
while there are ideas how it might be leveraged, there's no plan to do
so yet.
I agree, but it requires adding a second device and sometimes that's not
possible or tricky. I extrapolated a lot, but sometimes btrfs tools are
marketed as a "catch all" which can save the user from accidental
installations or updates and that's not always true.
4:05 p.m.
On Sat, Jul 18, 2020 at 12:51 PM Andy Mender <andymenderunix(a)gmail.com> wrote:
On Sun, 12 Jul 2020 at 18:09, Chris Murphy <lists(a)colorremedies.com> wrote:
>
> On Sun, Jul 12, 2020 at 5:39 AM Andy Mender <andymenderunix(a)gmail.com> wrote:
> >
> >On updates, a single automatic corrupted snapshot can
> > potentially hose the entire snapshotted volume.
>
> How do you mean? If this is a sort of superficial corruption like a
> bad/failed/partial update, inconsistency between package manager and
> what's installed - this can be self-contained to a specific snapshot.
> One possible idea for updates is snapshot and do the update out of
> band (not the current running sysroot) on a snapshot. If the update
> fails for whatever reason, destroy the snapshot. Corruption that
> affects multiple subvolumes wouldn't be related to snapshotting, but
> the shared trees: extent, chunk, csum, uuid, etc. trees.
I'm sorry, I should've been a little more specific. What I meant was that a
corrupted snapshot can potentially impact the subvolume and put it in a state in which
simply deleting the latest snapshot is not going to help or can't easily be done.
It depends on the nature of the corruption. If it's file system
corruption, e.g. due to some kind of hardware problem, then yeah it
could affect any number of things and not be isolated to a particular
subvolume.
Whereas if I make a snapshot and intentionally corrupt it, e.g. by
deleting half the files in it, and truncating the rest - all of those
changes are isolated to the snapshot and in no way affect the original
subvolume.
>
>
> >Also, if your system is almost broken after the change,
> > no snapshot will help.
>
> I'm not sure about the nature of the brokenness in your example. Btrfs
> does have a concept of a volume wide snapshot, which is the seed
> device. The file system is merely marked read-only, but can have a
> second device added that accepts all writes. If this two device volume
> were to become irreversibly confused, it'd still be possible to revert
> to the read-only device - even temporarily - as a kind of "recovery"
> boot. With extreme prejudice, a true factory reset is possible by
> wiping the read-write 2nd device and starting over. It's also possible
> to use it for replication - by adding a 2nd device and removing the
> 1st, an exact copy is made. This is a whole separate ball of wax, and
> while there are ideas how it might be leveraged, there's no plan to do
> so yet.
>
I agree, but it requires adding a second device and sometimes that's not possible or
tricky.
Yeah, anyone using that particular feature would have something like
an A/B partition setup as the two devices. The A partition would be
the read-only "recovery" image, and the second device is just a second
partition that accepts the changes from A. And in fact, you can boot
either A or B. Or you could even boot C, made from A and a ramdisk as
a volatile 2nd device.
I extrapolated a lot, but sometimes btrfs tools are marketed as a
"catch all" which can save the user from accidental installations or updates and
that's not always true.
Do you have an example? I'm not sure I follow.
In my case, I'm not using any automated tools. I don't consistently
take snapshots before updates. If I don't make a snapshot, and foul an
update somehow, Btrfs offers no magic solution for that. If I do make
a snapshot first - I can do (and have done) truly vile and malicious
things like rm -rf / and watch everything pancake; but I can pull the
plug, boot, point to the snapshot as the new root, and the system
boots fine. The messed up original root subvolume can just be deleted.
--
Chris Murphy
1380
days inactive
1387
days old
5 comments
4 participants
participants (4)
-
Andy Mender -
Chris Murphy -
Michel Alexandre Salim -
Neal Becker