On Monday 8 June 2020 11:01:03 PM IST Darrick J. Wong wrote: > On Sat, Jun 06, 2020 at 01:57:38PM +0530, Chandan Babu R wrote: > > The commit xfs: fix inode fork extent count overflow > > (3f8a4f1d876d3e3e49e50b0396eaffcc4ba71b08) mentions that 10 billion > > per-inode data fork extents should be possible to create. However the > > corresponding on-disk field has an signed 32-bit type. Hence this > > patchset extends the on-disk field to 64-bit length out of which only > > the first 47-bits are valid. > > > > Also, XFS has a per-inode xattr extent counter which is 16 bits > > wide. A workload which > > 1. Creates 1 million 255-byte sized xattrs, > > 2. Deletes 50% of these xattrs in an alternating manner, > > 3. Tries to insert 400,000 new 255-byte sized xattrs > > causes the following message to be printed on the console, > > > > XFS (loop0): xfs_iflush_int: detected corrupt incore inode 131, total extents = -19916, nblocks = 102937, ptr ffff9ce33b098c00 > > XFS (loop0): xfs_do_force_shutdown(0x8) called from line 3739 of file fs/xfs/xfs_inode.c. Return address = ffffffffa4a94173 > > > > This indicates that we overflowed the 16-bits wide xattr extent > > counter. > > > > I have been informed that there are instances where a single file > > has > 100 million hardlinks. With parent pointers being stored in xattr, > > we will overflow the 16-bits wide xattr extent counter when large > > number of hardlinks are created. Hence this patchset extends the > > on-disk field to 32-bit length. > > > > This patchset also includes the previously posted "Fix log reservation > > calculation for xattr insert operation" patch as a bug fix. It > > replaces the xattr set "mount" and "runtime" reservations with just > > one static reservation. Hence we don't need the functionality to > > calculate maximum sized 'xattr set' reservation separately anymore. > > > > The patches can also be obtained from > > https://github.com/chandanr/linux.git at branch xfs-extend-extent-counters. > > > > Chandan Babu R (7): > > xfs: Fix log reservation calculation for xattr insert operation > > What happened to that whole patchset with struct xfs_attr_set_resv > and whatnot? Did all that get condensed down to this single patch? Yes, with the new method, we have just one static log reservation rather than having "mount" and "runtime" reservations for the xattr set operation. The single static log reservation takes into account the worst case possible. i.e. - Double split of the Dabtree for large local xattrs. - Bmbt blocks required for mapping the contents of a maximum sized (i.e. XATTR_SIZE_MAX bytes in size) remote attribute. -- chandan
