On Sun, Sep 22, 2019 at 1:07 PM Pete <pete@xxxxxxxxxxxxxxx> wrote: > > On 9/22/19 6:47 PM, Chris Murphy wrote: > > >> Unfortunately I don't seem to have any more info in dmesg of the enospc > >> errors: > > > > You need to mount with enospc_debug to get more information, it might > > be useful for a developer. This -28 error is one that has mostly gone > > away, I don't know if the cause was ever discovered, but my > > recollection is once you're hitting it, you're better off creating a > > new file system rather than chasing it. > > > > But you could use 5.2.15 or newer, mount with enospc_debug, and do > > filtered balance. You could start with 1% increments, e.g. -dusage=1, > > -dusage=2, up to 5. And then do it in 5% increments up to 70. The idea > > of that is just to try and avoid enospc while picking off the low > > hanging fruit first (the block groups with the most free space). At > > that point I would then start a full balance, no filter. Maybe that'll > > get it back on track. I haven't ever experienced this so this strategy > > is totally a spitball method of trying to fix it. There is some degree > > of metadata rewrites that happens as part of balance, and balance is > > pretty complicated, and not entirely deterministic - meaning it's > > plausible the filtered balance followed by a full balance could fix > > it. But I don't understand it well enough. > > OK, I'm building 5.2.17 now. Keen to avoid the corruption errors I was > hit by a few weeks back... May take a time as I'm in the middle of a > slow backup. Did you see corruption on this same file system? The 5.2 corruption bug has been fixed in 5.2.15. https://www.spinics.net/lists/stable-commits/msg129532.html I'm not aware of a way to fix it though. > I note that a filtered balance, though not hitting enospc and not > reporting any errors did seemed to relocate a chunk/extent (sorry, I > forget the terminology) but running it a second, third and so on time > got the same result. As if the balance reported doing some work, but > did not actually do it. I also had to reboot at one point as it seemed > to get stuck in a loop but alas I can't repeat this. With the extra > logical volume added there is certainly no lack of space relative to the > size of the filesystem. For sure you're running into some kind of bug. -- Chris Murphy
