On 2016-06-02 18:45, Henk Slager wrote:
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.
Also, since you're on a new enough kernel, try 'lazytime' in the mount
options as well, this defers all on-disk timestamp updates for up to 24
hours or until the inode gets written out anyway, but keeps the updated
info in memory. The only downside to this is that mtimes might not be
correct after an unclean shutdown, but most software will have no issues
with this.
--
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
