https://bugzilla.kernel.org/show_bug.cgi?id=209039 --- Comment #2 from mgutt (marc@xxxxxxx) --- Ok. This means as my filesystem has a blocksize (bsize) of 4 KiB (4096 bytes): xfs_info /dev/md1 meta-data=/dev/md1 isize=512 agcount=11, agsize=268435455 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 = reflink=1 data = bsize=4096 blocks=2929721331, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=521728, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 each extend can't be bigger than 8GB as mentioned in the docs: https://xfs.org/docs/xfsdocs-xml-dev/XFS_Filesystem_Structure//tmp/en-US/html/Data_Extents.html >If a file is zero bytes long, it will have no extents, di_nblocks and >di_nexents will be zero. Any file with data will have at least one extent, and >each extent can use from 1 to over 2 million blocks (221) on the filesystem. >For a default 4KB block size filesystem, a single extent can be up to 8GB in >length. Good to know. Maybe this information should be part of xfs_fsr output? At the moment it creates the impression with "ideal 674" and "can_save=3" that it could be more defragmentated. -- You are receiving this mail because: You are watching the assignee of the bug.
