On Thu, Jun 2, 2016 at 3:55 PM, MegaBrutal <megabru...@gmail.com> wrote: > 2016-06-02 0:22 GMT+02:00 Henk Slager <eye...@gmail.com>: >> What is the kernel version used? >> Is the fs on a mechanical disk or SSD? >> What are the mount options? >> How old is the fs? > > Linux 4.4.0-22-generic (Ubuntu 16.04). > Mechanical disks in LVM. > Mount: /dev/mapper/centrevg-rootlv on / type btrfs > (rw,relatime,space_cache,subvolid=257,subvol=/@) > I don't know how to retrieve the exact FS age, but it was created in > 2014 August. > > Snapshots (their names encode their creation dates): > > ID 908 gen 487349 top level 5 path @-snapshot-20160503000001 ...<snip> > ID 937 gen 521829 top level 5 path @-snapshot-20160602000001 > > Removing old snapshots is the most feasible solution, but I can also > increase the FS size. It's easy since it's in LVM, and there is plenty > of space in the volume group. > > Probably I should rewrite my alert script to check btrfs fi show > instead of plain df.
Yes I think that makes sense, to decide on chunk-level. You can see how big the chunks are with the linked show_usage.py program, most of 33 should be 1GiB as already very well explained by Austin. The setup looks all pretty normal and btrfs should be able to handle it, but unfortunately your fs is a typical example that one currently needs to monitor/tune a btrfs fs for its 'health' in order to keep it running longterm. You might want to change mount option relatime to noatime, so that you have less writes to metadata chunks. It should lower the scattering inside the metadata chunks. -- 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
