[opensuse] How to undo snapper rollback?
openSUSE Tumbleweed (20160411) (x86_64) system with / as btrfs. System was pretty much out of the box, with snapper taking snapshots etc with each zypper up etc. Due to certain problems with some updates, I did a snapper rollback to a certain snapshot number. I realized after I did that that now I cannot delete one snapshot. This is the one that got set as the default subvolume when I did the snapper rollback. How do I put the system "back" to the way it was, where I had the ability to delete all snapshots. I am assuming this means I have to change the subvolume back to whatever it is on default systems (I do not have another system to see what this should be), but I have no idea how to set about doing that; especially since this involves /. Any help will be much appreciated. --Moby -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
14.04.2016 18:44, Moby пишет:
openSUSE Tumbleweed (20160411) (x86_64) system with / as btrfs. System was pretty much out of the box, with snapper taking snapshots etc with each zypper up etc.
Due to certain problems with some updates, I did a snapper rollback to a certain snapshot number. I realized after I did that that now I cannot delete one snapshot. This is the one that got set as the default subvolume when I did the snapper rollback. How do I put the system "back" to the way it was, where I had the ability to delete all snapshots.
You did not. Installation sets root to the first snapshot. It is probably always number 1, but I would be interested too in knowing how we can find out what root was before. This snapshot cannot be deleted just like your current root. On my TW this snapshot has description "first root filesystem". So setting root back makes no sense if the only reason is to be able to delete all snapshots.
I am assuming this means I have to change the subvolume back to whatever it is on default systems (I do not have another system to see what this should be), but I have no idea how to set about doing that; especially since this involves /.
Boot from rescue media, mount root partition and do btrfs subvolume set-default N /path/where/you/mounted/it where N is subvolume ID from btrfs subvolume list /path/where/you/mounted/it But as I said, this is completely pointless.
Any help will be much appreciated.
--Moby
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Apr 14, 2016 at 10:47 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
14.04.2016 18:44, Moby пишет:
openSUSE Tumbleweed (20160411) (x86_64) system with / as btrfs. System was pretty much out of the box, with snapper taking snapshots etc with each zypper up etc.
Due to certain problems with some updates, I did a snapper rollback to a certain snapshot number. I realized after I did that that now I cannot delete one snapshot. This is the one that got set as the default subvolume when I did the snapper rollback. How do I put the system "back" to the way it was, where I had the ability to delete all snapshots.
You did not. Installation sets root to the first snapshot. It is probably always number 1, but I would be interested too in knowing how we can find out what root was before. This snapshot cannot be deleted just like your current root.
Maybe in /var/log/snapper.log I think 1 refers to the subvolume path naming convention used by openSUSE. nohostname:/ # btrfs sub list -t / ID gen top level path -- --- --------- ---- 257 627 5 .snapshots 258 823 257 .snapshots/1/snapshot 259 112 5 boot/grub2/i386-pc 260 112 5 boot/grub2/x86_64-efi 261 112 5 opt 262 112 5 srv 263 823 5 tmp 264 819 5 usr/local 265 820 5 var/crash 266 820 5 var/lib/libvirt/images 267 820 5 var/lib/mailman 268 820 5 var/lib/mariadb 269 820 5 var/lib/mysql 270 820 5 var/lib/named 271 820 5 var/lib/pgsql 272 823 5 var/log 273 820 5 var/opt 274 823 5 var/spool 275 820 5 var/tmp 328 486 257 .snapshots/44/snapshot 331 486 257 .snapshots/47/snapshot 332 486 257 .snapshots/48/snapshot 333 486 257 .snapshots/49/snapshot 334 486 257 .snapshots/50/snapshot 335 486 257 .snapshots/51/snapshot 336 486 257 .snapshots/52/snapshot 337 486 257 .snapshots/53/snapshot If you go to YaST2 > Snapper, the ID column contains a number <n> that I think correlates to the number in .snapshots/<n>/snapshot. But that has a subvolume ID used by Btrfs. If I choose the ID Line "48 & 49" in Snapper and delete it, this is what things look like in Btrfs land. nohostname:/ # btrfs sub list -t / ID gen top level path -- --- --------- ---- 257 833 5 .snapshots 258 833 257 .snapshots/1/snapshot 259 112 5 boot/grub2/i386-pc 260 112 5 boot/grub2/x86_64-efi 261 112 5 opt 262 112 5 srv 263 833 5 tmp 264 819 5 usr/local 265 820 5 var/crash 266 820 5 var/lib/libvirt/images 267 820 5 var/lib/mailman 268 820 5 var/lib/mariadb 269 820 5 var/lib/mysql 270 820 5 var/lib/named 271 820 5 var/lib/pgsql 272 835 5 var/log 273 820 5 var/opt 274 835 5 var/spool 275 820 5 var/tmp 328 486 257 .snapshots/44/snapshot 331 486 257 .snapshots/47/snapshot 334 486 257 .snapshots/50/snapshot 335 486 257 .snapshots/51/snapshot 336 486 257 .snapshots/52/snapshot 337 486 257 .snapshots/53/snapshot 340 828 257 .snapshots/54/snapshot Paths with 48 and 49 are now gone, which were subvolid's 332 and 333. nohostname:/ # btrfs sub get-default / ID 258 gen 824 top level 257 path .snapshots/1/snapshot Right now the default subvolume is 258, which is the same as for path .snapshots/1/snapshot, and 1 is the ID number used by snapper for the current snapshot. The older ones, 44 and 47, are presumably sticking around because in snapper I have two lines with ID = "47 & 50" and ID = "44 & 51" which I think are before and after snapshots for doing some sort of update or yast configuration change. Anyway, if I roll back to a snapshot, I should then be able to delete everything except that snapshot. There's always one snapshot that you can't delete because it's a rw snapshot currently in use. What is a read-only snapshot? nohostname:/ # btrfs sub list -rt / ID gen top level path -- --- --------- ---- 328 486 257 .snapshots/44/snapshot 331 486 257 .snapshots/47/snapshot 334 486 257 .snapshots/50/snapshot 335 486 257 .snapshots/51/snapshot 336 486 257 .snapshots/52/snapshot 337 486 257 .snapshots/53/snapshot 340 828 257 .snapshots/54/snapshot So /1/ is definitely rw. If I do a rollback I think it snapshots one of the read-only snapshots to make a rw snapshot, and then uses set-default to change the default subvolume to that new rw subvolume's ID. I don't see a rollback option in Snapper GUI. *shrug* Am I missing it? I can do selective restore of files, but not entire rollbacks. So I guess I'll go to the CLI... nohostname:/ # snapper rollback 44 Creating read-only snapshot of current system. (Snapshot 57.) Creating read-write snapshot of snapshot 44. (Snapshot 58.) Setting default subvolume to snapshot 58. OK? What exactly did that do? nohostname:/ # btrfs sub list -t / ID gen top level path -- --- --------- ---- 257 849 5 .snapshots 258 848 257 .snapshots/1/snapshot 259 112 5 boot/grub2/i386-pc 260 112 5 boot/grub2/x86_64-efi 261 112 5 opt 262 112 5 srv 263 849 5 tmp 264 836 5 usr/local 265 820 5 var/crash 266 820 5 var/lib/libvirt/images 267 820 5 var/lib/mailman 268 820 5 var/lib/mariadb 269 820 5 var/lib/mysql 270 820 5 var/lib/named 271 820 5 var/lib/pgsql 272 847 5 var/log 273 820 5 var/opt 274 848 5 var/spool 275 820 5 var/tmp 328 849 257 .snapshots/44/snapshot 331 486 257 .snapshots/47/snapshot 334 486 257 .snapshots/50/snapshot 335 486 257 .snapshots/51/snapshot 336 486 257 .snapshots/52/snapshot 337 486 257 .snapshots/53/snapshot 340 828 257 .snapshots/54/snapshot 341 844 257 .snapshots/55/snapshot 342 845 257 .snapshots/56/snapshot 343 848 257 .snapshots/57/snapshot 344 849 257 .snapshots/58/snapshot nohostname:/ # btrfs sub list -tr / ID gen top level path -- --- --------- ---- 328 849 257 .snapshots/44/snapshot 331 486 257 .snapshots/47/snapshot 334 486 257 .snapshots/50/snapshot 335 486 257 .snapshots/51/snapshot 336 486 257 .snapshots/52/snapshot 337 486 257 .snapshots/53/snapshot 340 828 257 .snapshots/54/snapshot 341 844 257 .snapshots/55/snapshot 342 845 257 .snapshots/56/snapshot 343 848 257 .snapshots/57/snapshot nohostname:/ # btrfs sub get-default / ID 344 gen 849 top level 257 path .snapshots/58/snapshot Bunch of new snapshots, including /58/, which is rw since it's not in the read only list (cute inference, huh?) That snapshot is set as the default subvolume too. At next boot, the system will boot /58/, which should be a snapshot of /44/ since that's what I asked for with the snapper rollback command. Let's confirm? nohostname:/ # btrfs sub show /.snapshots/44/snapshot /.snapshots/44/snapshot Name: snapshot UUID: 7b13fcaf-f2d5-9e42-9729-ddefe5be0466 Parent UUID: 1228af4f-d512-614e-8c79-a280d2bcdffd Received UUID: - Creation time: 2016-03-25 19:17:56 -0400 Subvolume ID: 328 Generation: 849 Gen at creation: 253 Parent ID: 257 Top level ID: 257 Flags: readonly Snapshot(s): .snapshots/58/snapshot nohostname:/ # btrfs sub show /.snapshots/58/snapshot /.snapshots/58/snapshot Name: snapshot UUID: 8b309366-c044-ff43-af70-9a8b0cdd6f3a Parent UUID: 7b13fcaf-f2d5-9e42-9729-ddefe5be0466 Received UUID: - Creation time: 2016-04-14 21:23:10 -0400 Subvolume ID: 344 Generation: 849 Gen at creation: 849 Parent ID: 257 Top level ID: 257 Flags: - Snapshot(s): Yep. 'btrfs sub show' on the /44/ snapshot shows it is readonly, and that it has a snapshot named .snapshots/58/snapshot, and when I do 'show' on that /58/ snapshot I can see it references as parent UUID, the UUID of /44/ So the confusing thing to get over is that snapper is using its own IDs that are separate from Btrfs subvolume IDs. And for Btrfs newcomers maybe confusing is the distinction between subvolume and snapshots. They're really the same thing. A snapshot is a pre-populated subvolume, and it can be flagged readonly or not, by default it's not, therefore it's read write. And there is only a metadata relationship between "parent" and "child" snapshots; unlike ZFS it's possible to delete parents right away, you don't have to delete children first. Because a "child" becomes independent right away, either parent or child can be modified with writes, I feel like there's less of a tendancy to refer to snapshots as parent and child in the Btrfs world. It does come up occasionally, because, look at 'btrfs show' and you see "Parent UUID" so there is such a concept, but it's a pretty soft relationship. OK moving on. Let's say I want to revert back to /1/ because I haven't rebooted or made any changes, so why not? nohostname:/ # snapper rollback 1 Creating read-only snapshot of current system. (Snapshot 59.) Creating read-write snapshot of snapshot 1. (Snapshot 60.) Setting default subvolume to snapshot 60. OK that's one way to do it I guess... Looks like there is no going back to the same filesystem tree/subvolume ID. But as it's a snapshot it is pretty much the same thing. However, keep in mind that since I'm currently booted still in /1/ any changes now are going in /1/ and not into /60/ so I probably ought to reboot sooner than later. Hmm, failed to start modem manager, failed to start network manager, failed to start avahi, lots of failures on the next boot. It's not exactly revealing why... OK force power off. Choose the last (probably the oldest) read only snapshot from the GRUB menu. That works. But rootfs is readonly. So I'll try again, snapper rollback 1, and then reboot. Now it works. So maybe the double rollback without rebooting confused something. *shrug* no worse for the wear though I guess. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
15.04.2016 05:41, Chris Murphy пишет:
On Thu, Apr 14, 2016 at 10:47 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
14.04.2016 18:44, Moby пишет:
openSUSE Tumbleweed (20160411) (x86_64) system with / as btrfs. System was pretty much out of the box, with snapper taking snapshots etc with each zypper up etc.
Due to certain problems with some updates, I did a snapper rollback to a certain snapshot number. I realized after I did that that now I cannot delete one snapshot. This is the one that got set as the default subvolume when I did the snapper rollback. How do I put the system "back" to the way it was, where I had the ability to delete all snapshots.
You did not. Installation sets root to the first snapshot. It is probably always number 1, but I would be interested too in knowing how we can find out what root was before. This snapshot cannot be deleted just like your current root.
Maybe in /var/log/snapper.log
I think 1 refers to the subvolume path naming convention used by openSUSE.
Yes, and "snapper list" output.
nohostname:/ # btrfs sub list -t / ID gen top level path -- --- --------- ---- 257 627 5 .snapshots 258 823 257 .snapshots/1/snapshot
This one. ...
I don't see a rollback option in Snapper GUI. *shrug* Am I missing it?
Rollback as documented is really intended to be used from read-only snapshot boot. If something goes wrong you boot into one of existing read-only snapshots and then call "snapper rollback" to make it (well, its clone actually) your permanent root. So there is no GUI because you are never really supposed to use GUI. ...
OK moving on. Let's say I want to revert back to /1/ because I haven't rebooted or made any changes, so why not?
nohostname:/ # snapper rollback 1 Creating read-only snapshot of current system. (Snapshot 59.) Creating read-write snapshot of snapshot 1. (Snapshot 60.) Setting default subvolume to snapshot 60.
OK that's one way to do it I guess... Looks like there is no going back to the same filesystem tree/subvolume ID. But as it's a snapshot
Yes, which is one of things I actively do not like in SUSE implementation. Compare this with Solaris "boot environment" where you have multiple alternative versions of root and can switch between them (by "activating" boot environment).
it is pretty much the same thing. However, keep in mind that since I'm currently booted still in /1/ any changes now are going in /1/ and not into /60/ so I probably ought to reboot sooner than later.
Hmm, failed to start modem manager, failed to start network manager, failed to start avahi, lots of failures on the next boot. It's not exactly revealing why... OK force power off. Choose the last (probably
Sounds like a bug, although I am not sure to which extent this feature was tested ("rollback" from live system).
the oldest) read only snapshot from the GRUB menu. That works. But rootfs is readonly.
Of course. When you boot from snapshot in GRUB you boot into read-only subvolume.
So I'll try again, snapper rollback 1, and then reboot. Now it works.
So maybe the double rollback without rebooting confused something. *shrug* no worse for the wear though I guess.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/14/2016 11:01 PM, Andrei Borzenkov wrote:
15.04.2016 05:41, Chris Murphy пишет:
On Thu, Apr 14, 2016 at 10:47 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
14.04.2016 18:44, Moby пишет:
openSUSE Tumbleweed (20160411) (x86_64) system with / as btrfs. System was pretty much out of the box, with snapper taking snapshots etc with each zypper up etc.
Due to certain problems with some updates, I did a snapper rollback to a certain snapshot number. I realized after I did that that now I cannot delete one snapshot. This is the one that got set as the default subvolume when I did the snapper rollback. How do I put the system "back" to the way it was, where I had the ability to delete all snapshots.
You did not. Installation sets root to the first snapshot. It is probably always number 1, but I would be interested too in knowing how we can find out what root was before. This snapshot cannot be deleted just like your current root.
Maybe in /var/log/snapper.log
I think 1 refers to the subvolume path naming convention used by openSUSE.
Yes, and "snapper list" output.
nohostname:/ # btrfs sub list -t / ID gen top level path -- --- --------- ---- 257 627 5 .snapshots 258 823 257 .snapshots/1/snapshot
This one. ...
I don't see a rollback option in Snapper GUI. *shrug* Am I missing it?
Rollback as documented is really intended to be used from read-only snapshot boot. If something goes wrong you boot into one of existing read-only snapshots and then call "snapper rollback" to make it (well, its clone actually) your permanent root. So there is no GUI because you are never really supposed to use GUI.
...
OK moving on. Let's say I want to revert back to /1/ because I haven't rebooted or made any changes, so why not?
nohostname:/ # snapper rollback 1 Creating read-only snapshot of current system. (Snapshot 59.) Creating read-write snapshot of snapshot 1. (Snapshot 60.) Setting default subvolume to snapshot 60.
OK that's one way to do it I guess... Looks like there is no going back to the same filesystem tree/subvolume ID. But as it's a snapshot
Yes, which is one of things I actively do not like in SUSE implementation. Compare this with Solaris "boot environment" where you have multiple alternative versions of root and can switch between them (by "activating" boot environment).
it is pretty much the same thing. However, keep in mind that since I'm currently booted still in /1/ any changes now are going in /1/ and not into /60/ so I probably ought to reboot sooner than later.
Hmm, failed to start modem manager, failed to start network manager, failed to start avahi, lots of failures on the next boot. It's not exactly revealing why... OK force power off. Choose the last (probably
Sounds like a bug, although I am not sure to which extent this feature was tested ("rollback" from live system).
the oldest) read only snapshot from the GRUB menu. That works. But rootfs is readonly.
Of course. When you boot from snapshot in GRUB you boot into read-only subvolume.
So I'll try again, snapper rollback 1, and then reboot. Now it works.
So maybe the double rollback without rebooting confused something. *shrug* no worse for the wear though I guess.
Thanks to all those who replied. In the end, I take it there is no "easy" (involving something short of booting into rescue mode and changing default subvolume and then copying data over type activity) way to put the system back to an out-of-the-box state. -- --Moby -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Apr 15, 2016 at 7:26 PM, Moby <moby@mobsternet.com> wrote:
Thanks to all those who replied. In the end, I take it there is no "easy" (involving something short of booting into rescue mode and changing default subvolume and then copying data over type activity) way to put the system back to an out-of-the-box state.
Uhh, I don't know how you define out of the box. It sounds like you mean reverting to the exact same subvolume tree. But it's not clear why you disqualify a rollback that involves switching to a snapshot of the subvolume tree you want. It's the same thing, in effect. Maybe you could 'btrfs sub set-default X /" where X is the subvolume ID for the snapper ID of 1, which you'd have to find with 'btrfs sub list -t /'. I have no idea if there are consequences of switching default subvolumes outside of snapper, if it's doing its own tracking somehow. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/15/2016 09:01 PM, Chris Murphy wrote:
On Fri, Apr 15, 2016 at 7:26 PM, Moby <moby@mobsternet.com> wrote:
Thanks to all those who replied. In the end, I take it there is no "easy" (involving something short of booting into rescue mode and changing default subvolume and then copying data over type activity) way to put the system back to an out-of-the-box state.
Uhh, I don't know how you define out of the box. It sounds like you mean reverting to the exact same subvolume tree. But it's not clear why you disqualify a rollback that involves switching to a snapshot of the subvolume tree you want. It's the same thing, in effect.
Maybe you could 'btrfs sub set-default X /" where X is the subvolume ID for the snapper ID of 1, which you'd have to find with 'btrfs sub list -t /'. I have no idea if there are consequences of switching default subvolumes outside of snapper, if it's doing its own tracking somehow.
Thanks Chris. I would define "out of the box" just as you say - basically such that if the machine were handed to someone else, they would not be able to tell that a snapper rollback was done. -- --Moby -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Apr 15, 2016 at 8:04 PM, Moby <moby@mobsternet.com> wrote:
On 04/15/2016 09:01 PM, Chris Murphy wrote:
On Fri, Apr 15, 2016 at 7:26 PM, Moby <moby@mobsternet.com> wrote:
Thanks to all those who replied. In the end, I take it there is no "easy" (involving something short of booting into rescue mode and changing default subvolume and then copying data over type activity) way to put the system back to an out-of-the-box state.
Uhh, I don't know how you define out of the box. It sounds like you mean reverting to the exact same subvolume tree. But it's not clear why you disqualify a rollback that involves switching to a snapshot of the subvolume tree you want. It's the same thing, in effect.
Maybe you could 'btrfs sub set-default X /" where X is the subvolume ID for the snapper ID of 1, which you'd have to find with 'btrfs sub list -t /'. I have no idea if there are consequences of switching default subvolumes outside of snapper, if it's doing its own tracking somehow.
Thanks Chris. I would define "out of the box" just as you say - basically such that if the machine were handed to someone else, they would not be able to tell that a snapper rollback was done.
Well, if they don't know where to go looking, they wouldn't know. Functionally the binaries, dates, everything, in the rollback are identical. It's just that the subvolume tree numbers are different. The extents that are references are all the same. However, there might be a work around: Btrfs seed device. The original volume set as a seed device is read-only. It's possible to mount it (read only), add a separate block device (usb stick, anything really), remount rw and now you can do all kinds of things and the changes are all COW only to the added device. You can add and delete whatever you want and on this "sprout" volume that's made up of the ro original and rw added device, those changes take effect. You can't see deleted things. But if you umount, unset seed flag setting on original and mount the original, now it's back the way it was, no changes. Of course as soon as you make changes to the original again, the sprout is busted. It can't (reliably) be used anymore. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Apr 14, 2016 at 10:01 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
15.04.2016 05:41, Chris Murphy пишет:
Rollback as documented is really intended to be used from read-only snapshot boot. If something goes wrong you boot into one of existing read-only snapshots and then call "snapper rollback" to make it (well, its clone actually) your permanent root. So there is no GUI because you are never really supposed to use GUI.
If snapper wants rollbacks done only from read-only snapshot boots, it should disallow me from using rollback subcommand from rw snapshot boot. *shrug* If it's a snapper limitation, OK fine, but then inform me or deny the option. It's definitely not a btrfs limitation, it doesn't care about switching default subvolumes as many times as you want back to back. I don't know why you wouldn't want to use the GUI to do a rollback though.
OK that's one way to do it I guess... Looks like there is no going back to the same filesystem tree/subvolume ID. But as it's a snapshot
Yes, which is one of things I actively do not like in SUSE implementation. Compare this with Solaris "boot environment" where you have multiple alternative versions of root and can switch between them (by "activating" boot environment).
I think the GRUB readonly snapshot listing is confusing. Right now every item in the list is named the same, with each name's tail end cut off so I don't really know what I'm booting. It's sort of a guess. And the YaST2+snapper GUI has a lot of snapshots in it that don't really cue me in to what the differences are in a summary. I'd like to see openSUSE maybe label the snapshot right before a system update as a particular rollback candidate that goes in the GRUB menu, and in a less verbose snapper menu; and label it by date like, "openSUSE Tumbleweed 20160404" and so on, so that I can pick a date to rollback to, rather than 20 snapshots on that date. I can see where a bunch of snapshots are handy if I want to restore a specific file. But if I want to rollback due to a bad update, I really only need 2 or at most 4 options for rolling back to. One day I'd like to see these be named trees such that anyone with the exact same named tree has the same versions of all relevant "core" binaries.
it is pretty much the same thing. However, keep in mind that since I'm currently booted still in /1/ any changes now are going in /1/ and not into /60/ so I probably ought to reboot sooner than later.
Hmm, failed to start modem manager, failed to start network manager, failed to start avahi, lots of failures on the next boot. It's not exactly revealing why... OK force power off. Choose the last (probably
Sounds like a bug, although I am not sure to which extent this feature was tested ("rollback" from live system).
Yeah the whole thing blew up subsequently. It may be (inadvertent) user sabotage, I had the VM on a qemu disk with cache set to unsafe, so that might have thwarted Btrfs COW. I did file an upstream bug and mentioned the mess on the list, just in case it's relevant to making Btrfs better. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (3)
-
Andrei Borzenkov -
Chris Murphy -
Moby