On Sat, Dec 16, 2017 at 12:07 AM, Hans van Kranenburg <hans.van.kranenb...@mendix.com> wrote: > On 12/15/2017 09:53 AM, Qu Wenruo wrote: >> On 2017年12月15日 16:36, Ian Kumlien wrote: >>> On Fri, Dec 15, 2017 at 6:34 AM, Roman Mamedov <r...@romanrm.net> wrote: >>>> On Fri, 15 Dec 2017 01:39:03 +0100 >>>> Ian Kumlien <ian.kuml...@gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> Running a 4.14.3 kernel, this just happened, but there should have >>>>> been another 20 gigs or so available. >>>>> >>>>> The filesystem seems fine after a reboot though >>>> >>>> What are your mount options, and can you show the output of "btrfs fi >>>> df" and "btrfs fi us" for the filesystem? And what does >>>> "cat /sys/block/sdb/queue/rotational" return. >>> >>> It's a btrfs raid1 mirror of two ssd:s >>> >>> mount options was: >>> defaults,acl,noatime,space_cache,autodefrag,compress=lzo >>> >>> btrfs fi df / >>> Data, RAID1: total=459.25GiB, used=372.42GiB >>> Data, single: total=8.00MiB, used=0.00B >>> System, RAID1: total=8.00MiB, used=80.00KiB >>> System, single: total=4.00MiB, used=0.00B >>> Metadata, RAID1: total=6.00GiB, used=3.69GiB >> >> Both meta and data has a lot of space let. > > The real question is how fragmented that free space is.
Somewhat fragmented i'd say > Here's a good starting point to read up about the -o ssd behavior pre 4.14: > > https://www.spinics.net/lists/linux-btrfs/msg70622.html Will do [--8<--] >>> Unallocated: >>> /dev/sdb2 24.00KiB >>> /dev/sdc2 20.02MiB >> >> Well, at least no new chunk can be allocated. > > Exactly. After running: btrfs balance start -dusage=50 / a few times (first one failed but freed 6 gigs) it's now: Unallocated: /dev/sdb2 13.25GiB /dev/sdc2 13.26GiB >> In v4.15, Josef introduced a new inode reservation system, which I think >> it would enhance metadata related reservation. >> >> If you're hitting the problem quite frequently, please consider to try >> v4.15-rc* to see if it solves the problem. >> >> Despite of that, there should be no damage to your fs. >> (except some unwritten data in buffer) >> >> Thanks, >> Qu >> >>> >>> And as expected: >>> cat /sys/block/sdb/queue/rotational >>> 0 >>> >>>> I wonder if it's the same old "ssd allocation scheme" problem, and no >>>> balancing done in a long time or at all. > > Looks like it. So, yay, you're on 4.14 already. Now just do a full > balance of your entire filesystem, only once (data only, metadata not > needed) and then you can forget about this again. Any special filters etc needed? >>> I had something similar happen on a laptop a while ago - took a while >>> before i could get it back in order >>> (in that case i think it was actually a oops --- it kept saying "no >>> space left" and switched to read only even >>> if you removed a lot of data, invalidated the space cache and so on) > > -- > Hans van Kranenburg -- 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
