BTRFS/Rollback & Yum Snapshot Plugin

[Neal Becker]

Chris Murphy wrote:

> 
> On Jan 30, 2014, at 6:02 PM, Jorge Fábregas <jorge.fabregas at gmail.com> wrote:
>> 
>> #btrfs subvolume list /
>> ID 257 gen 102 top level 5 path root
>> ID 258 gen 102 top level 5 path home
>> ID 278 gen 95 top level 257 path yum_20140130172422
> 
> FYI note the top level is 257 which is root subvolume, therefore this entry is
> the same as saying "top level 5 path root/yum_20140130172422"
> 
>> 
>> # mount -o subvolid=5 /dev/vda3 /mnt
>> # btrfs subvolume delete /mnt/root
>> Delete subvolume '/mnt/root'
>> ERROR: cannot delete '/mnt/root' - Device or resource busy
> 
>> I believe this is happening because the snapshots are being created
>> WITHIN the subvolume they're snapshotting against.
> 
> Correct.
> 
>> Can you modify the yum plugin so that it places its
>> snapshots within OTHER particular subvolume?
> 
> I think a bug should be filed. It's a bug/RFE.
> 
> Another option is to look at snapper. It uses a subvolume at the top level
> called .snapper that it puts snapshots into. It's in the fedora repo.
> 
> 
>> BTW,  is there anyone out there using this plugin with btrfs?
> 
> I'm not, partly for the reason that I don't want snapshots available in the
> normally mounted fs because I find it a bit confusing, and also because it
> does as you say, it anchors root, boot, home subvolumes. Maybe I want to
> delete them if I get a totally messed up update that's beyond repair or my
> interest.
> 
> Do you know if these are read only snapshots?
> 
> btrfs sub show /home/yum_20140130172422
> 
>> p.d. I know snapshotting /home doesn't make sense at all for yum updates
>> but I followed it along…
> 
> I'm not bothered by it but the purpose for snapshot-rollback of boot and root
> vs home are different. Maybe for /home we'd want hourly snapshots. And we'd
> probably never rollback /home for a bad system update. We'd keep existing
> home, and all of its changes since updating. And then just rollback boot and
> root.
> 
> And on devel@ this was discussed that perhaps finer granularity is needed than
> what we presently have. For example I have an additional subvolume called
> journald at the top level which fstab mounts as:
> 
> UUID=xxx   /var/log/journal        btrfs   subvol=journald,compress=lzo,ssd
> 
> This is because for now I've decided I don't want snapshots having their own
> independent journal. I want a "master" journal kept up to date regardless of
> what snapshot I boot. But it may turn out this is not a good idea since the
> journal entries don't necessarily indicate what snapshot I've booted.
> 
> 
> 
> Chris Murphy
>

I filed this BR: 
https://bugzilla.redhat.com/show_bug.cgi?id=1060241