On Friday 19 June 2020 8:08:46 PM IST Christoph Hellwig wrote: > On Sat, Jun 06, 2020 at 01:57:44PM +0530, Chandan Babu R wrote: > > This commit extends the per-inode data extent counter to 47 bits. The > > length of 47-bits was chosen because, > > Maximum file size = 2^63. > > Maximum extent count when using 64k block size = 2^63 / 2^16 = 2^47. > > What is the use case for a large nuber of extents? I'm not sure why > we'd want to bother, but if there is a good reason it really should > be documented here. > > Late last year, Dave had pointed me to the commit "xfs: fix inode fork extent count overflow" (3f8a4f1d876d3e3e49e50b0396eaffcc4ba71b08) where the following scenario is described, Fallocate 40TiB of disk space and then alternatively punch out fs blocks. Assuming 4k block size, this would give, 40TiB / 4k / 2 = ~5 billion extents. This won't fit into a unsigned 32-bit field which can hold a maximum value of ~4 billion. Dave mentioned that we will go over the 32-bit extent counter limit soon. Hence this patch extends the on-disk data fork extent counter to a 64-bit field. In my next version of this patchset, I will add the technical part of the above description to the patch. Sorry for missing that out. -- chandan
