On Fri, Jan 12, 2018 at 09:38:22PM +0000, Kani, Toshi wrote: > On Sat, 2018-01-13 at 08:19 +1100, Dave Chinner wrote: > : > > IOWs, what you are seeing is trying to do a very large allocation on > > a very small (8GB) XFS filesystem. It's rare someone asks to > > allocate >25% of the filesystem space in one allocation, so it's not > > surprising it triggers ENOSPC-like algorithms because it doesn't fit > > into a single AG.... > > > > We can probably look to optimise this, but I'm not sure if we can > > easily differentiate this case (i.e. allocation request larger than > > continguous free space) from the same situation near ENOSPC when we > > really do have to trim to fit... > > > > Remember: stripe unit allocation alignment is a hint in XFS that we > > can and do ignore when necessary - it's not a binding rule. > > Thanks for the clarification! Can XFS allocate smaller extents so that > each extent will fit to an AG? I've already answered that question: I'm not sure if we can easily differentiate this case (i.e. allocation request larger than continguous free space) from the same situation near ENOSPC when we really do have to trim to fit... > ext4 creates multiple smaller extents for the same request. Yes, because it has much, much smaller block groups so "allocation > max extent size (128MB)" is a common path. It's not a common path on XFS - filesystems (and hence AGs) are typically orders of magnitude larger than the maximum extent size (8GB) so the problem only shows up when we're near ENOSPC. XFS is really not optimised for tiny filesystems, and when it comes to pmem we were lead to beleive we'd have mutliple terabytes of pmem in systems by now, not still be stuck with 8GB NVDIMMS. Hence we've spent very little time worrying about such issues because we weren't aiming to support such small capcities for very long... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
