Some update since last time (few weeks ago).All filesystems are mounted with noatime, I've also added mounting optimization - so there is no problem with remounting filesystem every time, it is done only once.
Remounting optimization helped by reducing 1 complete snapshot + send/receive cycle by some seconds, but otherwise it is still very slow when `btrfs receive` is active.
I'm not considering bcache + btrfs as potential setup because I do not currently have free SSD for it and basically spending SSD besides HDD for backup partition feels like a bit of overkill (especially for desktop use).
My current kernel is 4.5.0 stable, btrfs-tools still 4.4-1 from Ubuntu 16.04 repository as of today.
As I'm reading mailing list there are other folks having similar performance issues. So can we debug things to find the root cause and fix it at some point?
My C/C++/Kernel/BTRFS knowledges are scarce, which is why some assistance here is needed from someone more experienced.
Sincerely, Nazar Mokrynskyi github.com/nazar-pc Skype: nazar-pc Diaspora: nazarpc@xxxxxxxxxxxxxxxxxxxxxxx Tox: A9D95C9AA5F7A3ED75D83D0292E22ACE84BA40E912185939414475AF28FD2B2A5C8EF5261249 On 25.02.16 03:04, Henk Slager wrote:
On Wed, Feb 24, 2016 at 11:45 PM, Nazar Mokrynskyi <nazar@xxxxxxxxxxxxxx> wrote:Here is btrfs-show-super output:nazar-pc@nazar-pc ~> sudo btrfs-show-super /dev/sda1 superblock: bytenr=65536, device=/dev/sda1 --------------------------------------------------------- csum 0x1e3c6fb8 [match] bytenr 65536 flags 0x1 ( WRITTEN ) magic _BHRfS_M [match] fsid 40b8240a-a0a2-4034-ae55-f8558c0343a8 label Backup generation 165491 root 143985360896 sys_array_size 226 chunk_root_generation 162837 root_level 1 chunk_root 247023583232 chunk_root_level 1 log_root 0 log_root_transid 0 log_root_level 0 total_bytes 858993459200 bytes_used 276512202752 sectorsize 4096 nodesize 16384 leafsize 16384 stripesize 4096 root_dir 6 num_devices 1 compat_flags 0x0 compat_ro_flags 0x0 incompat_flags 0x169 ( MIXED_BACKREF | COMPRESS_LZO | BIG_METADATA | EXTENDED_IREF | SKINNY_METADATA ) csum_type 0 csum_size 4 cache_generation 165491 uuid_tree_generation 165491 dev_item.uuid 81eee7a6-774e-4bb5-8b72-cebb85a2f2ce dev_item.fsid 40b8240a-a0a2-4034-ae55-f8558c0343a8 [match] dev_item.type 0 dev_item.total_bytes 858993459200 dev_item.bytes_used 291072114688 dev_item.io_align 4096 dev_item.io_width 4096 dev_item.sector_size 4096 dev_item.devid 1 dev_item.dev_group 0 dev_item.seek_speed 0 dev_item.bandwidth 0 dev_item.generation 0It is sad that skinny metadata will only affect new data, probably, I'll end up re-creating it:( Can I rebalance it or something simple for this purpose?A balance won't help for that and also your metadata does look quite compact already. But I think you should not expect so much of this skinny metadata on a PC with 16G RAMThose are quite typical values for an already heavily used btrfs on a HDD.Bad news, since I'm doing mounting/unmounting few times during snapshots creation because of how BTRFS works (source code: https://github.com/nazar-pc/just-backup-btrfs/blob/master/just-backup-btrfs.php#L148) So if 10+20 seconds is typical, then in my case HDD can be very busy during a minute or sometimes more, this is not good and basically part or even real reason of initial question.Yes indeed! This mount/unmount every 15 minutes (or more times per 15 minutes) is killing for performance IMO. At the moment I don't fully understand why you are bothered by the limitation you mention in the php source comments. I think it's definitely worth to change paths and/or your requirements in such a way that you can avoid the umount/mount. As a workaround, bcache with its cache device nicely filled over time, will absolutely speedup the mount. But as you had some troubles with btrfs in the past and also you use ext4 on the same disk because it is a more mature filesystem, you might not want bache+btrfs for backup storage, it is up to you. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
smime.p7s
Description: Кріптографічний підпис S/MIME
