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. > -- > > With Best Regards, > Marat Khalili -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
