Re: number of subvolumes

[Chris Murphy <lists@colorremedies.com>]

On Thu, Aug 24, 2017 at 3:56 PM, Ferry Toth <ftoth@telfort.nl> wrote:
> Op Thu, 24 Aug 2017 22:40:54 +0300, schreef Marat Khalili:
>
>>> We find that typically apt is very slow on a machine with 50 or so
>>> snapshots and raid10. Slow as in probably 10x slower as doing the same
>>> update on a machine with 'single' and no snapshots.
>>>
>>> Other operations seem to be the same speed, especially disk benchmarks
>>> do not seem to indicate any performance degradation.
>>
>> For meaningful discussion it is important to take into account the fact
>
> Doing daily updates on a desktop is not uncommon and when 3 minutes
> become 30 then many would call that meaningfull.
>
> Similar for a single office server, which is upgraded twice a year, where
> an upgrade normally would take an hour or 2, but now more than a working
> day. In the meantime, take samba and postgresql offline, preventing
> people to work for a few hours.
>
> My point is: fsync is not targeted specifically in many common disk bench
> marks (phoronix?), it might be posible that there is no trigger to spend
> much time on optimizations in that area. That doesn't make it meaningless.
>
>> that dpkg infamously calls fsync after changing every bit of
>> information, so basically you're measuring fsync speed. Which is slow on
>> btrfs (compared to simpler filesystems), but unrelated to normal work.
>
> OTOH it would be nice if dpkg would at last start making use btrfs
> snapshot features and abandon these unnecssary fsyncs completely, instead
> restoring a failed install from a snapshot. This would probably result in
> a performance improve compared to ext4.
>
>> I've got two near-identical servers here with several containers each
>> different only on in filesystem: btrfs-raid1 on one (for historical
>> reasons) and ext4/mdadm-raid1 on another, no snapshots, no reflinks.
>> Each time containers on ext4 update several times faster, but in
>> everyday operation there's no significant difference.

In the thread "Containers, Btrfs vs Btrfs + overlayfs" there's the
idea of nullifying fsyncs in container contexts. Maybe it could be
adapted for out of band system software updates, i.e.

1. updater runs in a container
2. takes a snapshot of the system
3. assembles the snapshot per fstab
4. performs the OS update (within the container, on the snapshot),
filtering out fsync
5. does a sync() after completion of update
6. update bootloader configuration to point to the updated snapshot/file tree
7. quit container
8. user reboots whenever convenient to run the updated system

Basically this is still an atomic update that won't nerf either the
file system or the OS if there's a crash or power failure prior to
step 7. Any failure, just delete the snapshot (failed out of band
update). The existing tree isn't affected by either the update or the
failure so there's not even a problem running it while the user is
working, insofar as binaries and libraries aren't being yanked out
from under running processes, they're all out of band changes.

Something like this exists, but it's not package based, rather it's
"git like", and also has no optimizations for Btrfs. It's updates are
out of band, and always atomic, not matter the file system.

OSTree.

https://github.com/ostreedev/ostree
https://ostree.readthedocs.io/en/latest/

-- 
Chris Murphy