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. 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. > > Also I'd remove any snapshots you don't really need, it'll make the > balance less complicated and faster. > > There are not too many, but it does not do much harm to take a look.
